MongoDB — это не kv-хранилище, а документо-ориентированное.
NoSQL — это не более, чем маркетинговое название всех хранилищ (и баз данных в целом), в которых, если высказаться грубо, нет «сложного» sql (на самом деле, not only sql, хотя я практически присутствовал во время, когда nosql всплыл как нечто, что не более, чем очередной интернето-твиторо-мем): иерархические, документо-, объектно-ориентированные (но тут возможет страшный OQL), те же kv.
Опять же, никто не запрещает использовать те же mysql/postgresql/anysql как k/v хранилища. Индексируйте данные модным elasticsearch'ем и получайте их по ключу «select * from table where id = ?» (или и вовсе пройдите за пачкой данных напрямую в хранилище).
Хипсторство не ра-бо-та-ет, если вы не понимаете, для чего оно вам нужно.
А я, в свою очередь, вижу общую путаницу на тему БД, СУБД, SQL, NoSQL, KV, документо-ориентированные и хипста-ориентированные хранилища, базы дынных и систем управления базами данных. Что, в целом, меня немного расстраивает.
Проблемы, с которым сталкивается человечество при разработке архитектуры данных начинаются где-то около твитора или фейсбука — это многочисленные счётчики (замена update на append-only + моментальная агрегация), различные ссылки объектов туда-сюда, друг на друга, етц, в следствие возникают проблемы с расширяемостью, придумывают map-reduce и аналоги. И решают эти задачи отнюдь не на дедике в hetzner.net, а на, как минимум, десятке таких.
Глянуть на тот же достаточно взрывной Pinterest:
— Март 2010: MySQL
— Январь 2011: MongoDB
— Весна-лето 2012: MySQL — по сей день
На этом внезапно закончу, а то потянуло на графоманство. Думаю, Вы поняли о чём я :-)
Всё же, документация слабовата. Либо я слабоват на ночь глядя. Но если серьезно, не нашел ни в гайде, ни в api-документации. Так вот как бы мне рендерить этот виджет в момент, когда загрузятся данные?
Сегодня вечерком наткнулся на Joosy, бороздя гитхаб. Зашел на сайт, читнул гайд — заинтересовало. Рассказал коллегам. Часа два назад сел реализовать микро-проект. Собственно, для него я и ходил по гитхабу, обыскивая решения с backbone или ember.js, взвешивал что и как, ибо хотелось попробовать что нибудь отличное от Backbone, есть неудобные моменты, а тут Joosy. В общем, сделал я что хотел, не потратив времени на бутстреп рельсового проекта и прочего, и прочего. Красота, в общем.
Но возник у меня вопрос. Для примера возьму разработку блога из гайда. Собственно, вопрос: подскажите, пожалуйста, best practice для того, чтобы, скажем, был некоторый виджет(?) со списком всех постов на уровне лэйаута, то бишь, существующий на всех страницах, другими словами, некоторая глобальная навигация.
Пока писал, пришла в голову мысль, что я, похоже, что-то упустил в доках и мне нужны те самые «виджеты».
Почему записи удаляете как GET /main/delete/id, а не DELETE /resrource/id? Ну хотя бы POST с csrf_token что ли… Молодец, что показали что и как, но если уж показывать, то правильно.
Fulltext search используется далеко не только в поиске по сайту. Например, чтобы заменить 50-60 строчные sql-запросы сложные для переваривания sql-сервером.
С уважением, ваш некропостер
NoSQL — это не более, чем маркетинговое название всех хранилищ (и баз данных в целом), в которых, если высказаться грубо, нет «сложного» sql (на самом деле, not only sql, хотя я практически присутствовал во время, когда nosql всплыл как нечто, что не более, чем очередной интернето-твиторо-мем): иерархические, документо-, объектно-ориентированные (но тут возможет страшный OQL), те же kv.
Опять же, никто не запрещает использовать те же mysql/postgresql/anysql как k/v хранилища. Индексируйте данные модным elasticsearch'ем и получайте их по ключу «select * from table where id = ?» (или и вовсе пройдите за пачкой данных напрямую в хранилище).
Хипсторство не ра-бо-та-ет, если вы не понимаете, для чего оно вам нужно.
А я, в свою очередь, вижу общую путаницу на тему БД, СУБД, SQL, NoSQL, KV, документо-ориентированные и хипста-ориентированные хранилища, базы дынных и систем управления базами данных. Что, в целом, меня немного расстраивает.
Проблемы, с которым сталкивается человечество при разработке архитектуры данных начинаются где-то около твитора или фейсбука — это многочисленные счётчики (замена update на append-only + моментальная агрегация), различные ссылки объектов туда-сюда, друг на друга, етц, в следствие возникают проблемы с расширяемостью, придумывают map-reduce и аналоги. И решают эти задачи отнюдь не на дедике в hetzner.net, а на, как минимум, десятке таких.
Глянуть на тот же достаточно взрывной Pinterest:
— Март 2010: MySQL
— Январь 2011: MongoDB
— Весна-лето 2012: MySQL — по сей день
На этом внезапно закончу, а то потянуло на графоманство. Думаю, Вы поняли о чём я :-)
$ source ~/.bashrc
Пора спать, да.
Сегодня вечерком наткнулся на Joosy, бороздя гитхаб. Зашел на сайт, читнул гайд — заинтересовало. Рассказал коллегам. Часа два назад сел реализовать микро-проект. Собственно, для него я и ходил по гитхабу, обыскивая решения с backbone или ember.js, взвешивал что и как, ибо хотелось попробовать что нибудь отличное от Backbone, есть неудобные моменты, а тут Joosy. В общем, сделал я что хотел, не потратив времени на бутстреп рельсового проекта и прочего, и прочего. Красота, в общем.
Но возник у меня вопрос. Для примера возьму разработку блога из гайда. Собственно, вопрос: подскажите, пожалуйста, best practice для того, чтобы, скажем, был некоторый виджет(?) со списком всех постов на уровне лэйаута, то бишь, существующий на всех страницах, другими словами, некоторая глобальная навигация.
Пока писал, пришла в голову мысль, что я, похоже, что-то упустил в доках и мне нужны те самые «виджеты».
> выглядит неплохо что то в этом есть…
> в противном случае сервис будет остановлен, сервер выключен!
Попахивает делением на еденицу.