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

Question

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

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

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

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

Answer 1

Проверьте сравнение альтернатив SQL без BJ Clark .

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

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

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

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

Вы говорили:

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

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

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

Answer 2

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

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

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

Answer 3

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