MongoDB для AJAX в реальном времени? - PullRequest
2 голосов
/ 26 сентября 2010

Howdie stackoverflow люди!

Так что я занимался поисками этих баз данных NoSQL, MongoDB, CouchDB и т. Д. Хотя я все еще не уверен в вещах, требующих реального времени, поэтому я подумал, что спроситьвокруг, чтобы увидеть, есть ли у кого-то практический опыт.

Давайте подумаем о веб-вещах, скажем, у нас есть очень динамическое супер-ajaxified веб-приложение, которое запрашивает различные типы данных каждые 5-20 секунд, наш бэкэндpython или php или что-то иное, чем java на самом деле ... в таких случаях, как эти, очевидно, MySQL или аналогичные БД будут находиться под сильным давлением (с большим количеством пользователей), MongoDB / CouchDB запустит это без пота и без необходимостисоздать какое-то сверхсложное решение для кластера / кэширования и т.д.?

Да, это в основном мой вопрос, если вы считаете, что нет ... тогда да, я знаю, что есть несколько типов решений для этого, nodeJS / websockets / antigravity /червоточина супер техник, но я просто заинтересован в этих вещах NoSQL атм и более конкретноy, если они могут справиться с этим типом вещей.

Допустим, у нас есть 5000 пользователей одновременно, каждые 5, 10 или 20 секунд ajax-запросы, которые обновляют различные интерфейсы.

Shoot;]

Ответы [ 2 ]

2 голосов
/ 27 сентября 2010

Допустим, у нас есть 5000 пользователей одновременно, каждые 5, 10 или 20 секунд ajax-запросы, которые обновляют различные интерфейсы.

ОК, так что, чтобы получить это право, вы 'Вы говорите о 250-1000 записей в секунду?Да, MongoDB может справиться с этим.

Реальный ключ к производительности будет в том, являются ли они запросами, обновлениями или вставками.

Для запросов , Mongo можетвероятно справиться с этой нагрузкой.Это действительно будет о соотношении размера данных к объему памяти.Если у вас есть сервер с 1 ГБ ОЗУ и 150 ГБ данных, то вы, вероятно, не получите 250 запросов в секунду (с любой технологией БД).Но при разумных технических характеристиках оборудования Mongo может достичь этой скорости на одном 64-разрядном сервере.

Если у вас 5000 активных пользователей и вы постоянно обновляете существующие записи, Mongo будет работать очень быстро (наравне с обновлением).Memcached на одной машине).Причина в том, что Mongo, скорее всего, сохранит запись в памяти.Таким образом, пользователь будет отправлять обновления каждые 5 секунд, а объект в памяти будет обновляться.

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

Итак, исходя из ваших вопросов, похоже, что вы в основном запрашиваетеобновление.Вы будете писать новые записи, но не 1000 новых записей в секунду.Если это так, то MongoDB, вероятно, подходит именно вам.Это определенно обойдет множество проблем с кэшированием.

0 голосов
/ 26 сентября 2010

Это сильно зависит от сервера, на котором работает указанное решение NoSQL, количества данных и т. Д. Я немного поиграл с Mongo, и очень легко настроить одновременную работу нескольких серверов, и вы, скорее всего, сможете выполнить высокий параллелизм за счет запуска нескольких экземпляров в одном и том же блоке и их действия как кластера. К счастью, Mongo, по крайней мере, обрабатывает все особенности, так что серверы могут быть убиты и представлены без пропуска удара (в зависимости от версии). По умолчанию я считаю, что максимальное количество подключений составляет 1000, поэтому достаточно запустить 5 серверов с указанной конфигурацией (если ваш сервер может с этим справиться, очевидно), но в действительности вы, скорее всего, никогда не достигнете 5000 пользователей одновременно.

Надеюсь, ради вашего оборудования вы хотя бы найдете решение, которое может проверить наличие новых данных перед полной загрузкой. Либо с помощью меток времени, либо с помощью Memcache и т. Д. *

В целом, я склонен полагать, что NoSQL будет намного быстрее, чем традиционные базы данных, при условии, что вы извлекаете данные, не запускаете отчеты и т. Д. ... и ваш дизайн хранилища данных достаточно умен, чтобы компенсировать отсутствие сложных объединений.

...