Выбор технологии базы данных

Question

Мы собираемся создать онлайн-платформу (API, серверы, данные, Wahoo!).Для контекста представьте, что нам нужно создать что-то вроде Twitter, но с комментариями (твитами), организованными вокруг живого события.Информация о самом прямом событии должна доставляться клиентам как можно быстрее и последовательно, в то время как доставка комментариев о событии, вероятно, может занять немного больше времени.После завершения прямой трансляции мы будем заняты чтением.

Масштабируемость очень важна.Мы хотим начать с аренды VPS-фрагментов и затем масштабироваться.Я большой поклонник облака и хотел бы оставаться там как можно дольше.Вероятно, мы будем использовать Ruby.

Я убежден, что хочу попробовать хранилище документов вместо СУБД.Мне нравится идея хранения без схемы и обещания более простой масштабируемости за счет сосредоточения внимания на ключе-значении.

Проблема в том, что я не знаю, какая технология наиболее подходит для нашей платформы.Я рассмотрел Couch, Mongo, Tokyo Cabinet, Cassandra и СУБД с большими объемами документов.Любая помощь в выборе подходящего инструмента для этой конкретной работы?

Answer 1

Ознакомьтесь со сравнением альтернатив NO SQL по Би Джей Кларк.

Масштабируемость очень важна.

Тогда вам необходимо рассмотреть выдержки из его блога:

1. Токийский кабинет — не масштабируется
2. Redis — не масштабируется
3. Проект Волдеморт - весы
4. MongoDB - ограничено (реализовано шардинг)
5. Кассандра – весы
6. Amazon S3 — весы
7. Диван - Не масштабируется (Кластеризация и репликация)
8. MySQL – не масштабируется

И рассмотрим Гипертаблица.Это также серьезный конкурент среди альтернатив No-SQL.Это реализация концепции Google BigTable с открытым исходным кодом.Я считаю, что он хорошо масштабируется, поскольку широко используется китайской поисковой системой Baidu и развлекательным порталом Rediff.

Ты говорил:

Информация о самом живом мероприятии должна быть доставлена ​​клиентам как можно быстрее и последовательно, в то время как комментарии о событии, вероятно, могут подождать немного дольше, чтобы их можно было доставить.Мы будем читать после окончания живого мероприятия.

Это что-то вроде подхода Twitter.Выбор языка программирования также очень важен, поскольку Twitter изначально использовал Ruby для внутренней доставки сообщений, но они говорили это неправильный выбор и они перенесли всю систему доставки сообщений на Скала язык.

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

Answer 2

У Рамеша хорошее резюме.Я бы добавил, что у Кассандры более богатая модель данных, чем у ванильных клонов Динамо (таких как Волдеморт или Диномит):строки с именованными отсортированными столбцами, а не просто ключ/значение.Cassandra используется Twitter, Mahalo, Ooyala, SimpleGeo, WebEx и другими (http://n2.nabble.com/Cassandra-users-survey-td4040068.html), по крайней мере некоторые из которых используют кластеры Cassandra на облачных серверах EC2 или Rackspace.

Answer 3

Если вы хотите масштабировать горизонтально (распределять данные по более чем одному узлу), вам необходимо принять во внимание теорему CAP.

http://www.julianbrowne.com/article/viewer/brewers-cap-theorem

Это непростая задача, но вам придется выбирать, всегда есть какой-то компромисс.