LINUX.ORG.RU

NoSQL, проблемы выбора


0

3

Вобщем в двух словах это веб-проект, но пишу не в веб-девелопмент, поскольку, вопрос из разряда разработки сервер-сайд прокладки под веб и всё остальное. Это что-то вроде движка для голосований в котором пользователи не ограничены в кол-ве и размере комментариев к голосованию, при этом одновременно открытых голосований может быть до 2-х 3-х тысяч и самая засада тут в том, что каждый комментарий порождает оповещение одному или более участнику голосования. Вобщем, меня терзают смутные сомнения, что postgres'у (даже если оповещения вынести в... скажем redis) может от такой активности поплохеть. Голосования будут жить недолго 1-2 дня, но в первые часы из-за активного анонсирования и упрощения механизма комментирования в теории могут доходить до 20 комментов в секунду. Учитывая, что в постановке ТЗ требуется хранить 30-50 последнийх сообщений - напрашивается NoSQL решение, пока по обзорам подходит CouchDB, но уж очень неоднозначные отзывы, о таких решениях.

Собственно вопрос. Какие из NoSQL движков подойдут под такую модель (желательно умеющие master<->master репликацию)? Какие подводные камни ждут?

Заранее спасибо.


Ответ на: комментарий от iBliss

из за удобства и множества команд. в пределе конечно можно вообще свое специализированное что-то замутить, но сдается что redis хватит за глаза.

quest ★★★★
()
Ответ на: комментарий от quest

Спс. Всётаки без бенчмарков никак.

iBliss
() автор топика

CouchDB неплохая СУБД, но по ней достаточно мало информации в интернете, так что в случае каких-то проблем может потребоваться глубоко копать самому. Вообще имхо если нет проблем с типизацией данных (когда набор полей определяется в момент выполнения), проще использовать все-таки реляционную базу. Ну или если redis-а для твоей задачи действительно достаточно, возможно это будет хорошим выбором.

Dobriy_i_Prostoy
()

Мне кажется postgres отлично справится, если ты про скорость. Я сам тяготею к nosql, но в плане скорости mysql и postgres не настолько тормоза как обычно думают.

true_admin ★★★★★
()
Ответ на: комментарий от st4l1k

Не годится для частой записи.

Статистика? Собственный неудачный опыт? Пруф неопределённой степени левизны?

Или просто зазубренная мантра «nosql быстрее sql»? Тогда уж раскройте и секрет - чем приходится жертвовать для достижения «бешеной скорости вставки»?

А то весь этот треш вокруг nosql напоминает шаманские пляски укуренных маркетологов. Нет бы остановиться: для слабо/нечётко структурированных данных. Нет, начинается: мы быстрее всех! вы забудете ад sql-запросов (пля, тут даже в сишарп линк всобачили, а оказывается - старые тёплые ламповые `do while' круче всего), мы самые-самые!... И только в самом дальнем углу самым мелким шрифтом «если вам надо ....то вам таки лучше использовать sql rdbms».

А с другой стороны - используйте хоть dBAse-III, чей-то фейл - это всегда и чей-то вин ;)

yyk ★★★★★
()

Couch хороший, я его как-то пробовал - вполне хватает и документации, и примеров в интернете. С производительностью тоже неплохо, правда диск жрёт. Но зато кэширует результаты и переписывает только изменённые.

Хотя, конечно, необходимо протестировать под нагрузкой заранее, а то мало ли.

У couch-а есть большой недостаток (как минимум был) - невозможность писать запросы динамически, только вкручивая js в базу. То есть, на ходу формировать запрос по хитрым параметрам сообщения не получится - обязательно нужно, чтобы разработчик написал map/reduce код. Ну или написать некий универсальный map/reduce код для всех возможных запросов, но это костыльно очень.

А вот монго, например, умеет. Но в твоей задаче оно может и не понадобиться.

Тупо создай базу скриптом, набей случайными голосованиями и скриптом же протестируй.

anonymous
()
Ответ на: комментарий от quest

redis не умеет master-master

Сейчас redis cluster активно пилится, а на нём можно и master<->master запилить, если хочется.

mix_mix ★★★★★
()

В mongodb все оч хорошо с масштабированием/отказоустойчивостью если что

redixin ★★★★
()
Ответ на: комментарий от gh0stwizard

mongo master <-> master асинхронный! могут быть задержки и т.п., если что :)

4.2

redixin ★★★★
()
Ответ на: комментарий от LamerOk

Berkeley DB

Да она уже рассматривалась, но тут в поставленные сроки я скорее пальцы сломаю, чем выдам что-то надёжное.

iBliss
() автор топика

Постгря српавится. Но редис будет приятней.

namezys ★★★★
()

node4j или oriondb спасут от тяжелых join'ов. если узкое место не join, то голой innodb будет достаточно.

anonymous
()

подходит CouchDB

Нет, медленно. Коуч не предназначен для частой записи. Его плюс только в надежности и атомарности всех операций.

Более того, коуч (и монго) - документные базы. А у вас плоские записи.

Возьмите редис.

iSage ★★★★
()
Ответ на: комментарий от st4l1k

На самом деле ничего страшного не случается, если у вас хотя бы 4 честных ядра.
На двух все печально, все съедается перестройкой вьюх.

Тут, правда, есть хитрости. Не стоит сразу после вставки искать обьект через вьюху, надо брать по _id.

Мы в коуче храним юзеров всех проектов (сейчас около 200к), к новому году будет еще около 700к. В io и проц пока не упирались. Впрочем, у нас редкие записи и частое чтение. С другой стороны, при импорте юзеров с очередного проекта (до 100к записей) все продолжает работать.

iSage ★★★★
()

постгря тоже может быть nosql

Rastafarra ★★★★
()
Ответ на: комментарий от pawnhearts

(про коуч) - на записи. рекомендую монго. что могу положительного сказать о ней-_очень_ быстрые апдейты. ну и репликация да если надо и т.п.

pawnhearts ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.