2014-11-20 4 views
0

Я работаю в крупной компании, у которой есть проблемы с работой с нагрузкой на серверные системы. Они смотрят на замену своей старой устаревшей системы/базы данных и заменяют ее горизонтально масштабируемой базой данных NoSQL. Причина поиска баз данных NoSQL должна быть готова к будущему с использованием масштабируемого по горизонтали решения.Различия в базах данных NoSQL и вероятности проблем с несоответствием

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

Существует множество систем баз данных NoSQL (cassandra, mongoDB, hbase и т. Д.). Существуют ли какие-либо рекомендации или имеется ли литература, по которой системы баз данных подходят в каких случаях? Я также хочу получить представление о том, насколько вероятно, что это связано с проблемами непоследовательности и как уменьшить этот шанс и с какой ценой.

Любая информация/советы/ссылки на литературу приветствуются.

ответ

0

Там в тонны информации там ... Google является вашим другом :)

Я очень рекомендую Кассандру. Он довольно прост в настройке и безмолвенный + отказоустойчивый. Вы можете указать, сколько репликации вы хотите использовать для каждой базы данных, и это будет для вас. Он также может выполнять кросс-репликацию центра обработки данных. Он имеет настраиваемую согласованность. Если вы хотите, для определенных бит данных вы можете достичь полной согласованности (например, жертвуя доступностью во время записи). Таким образом, это не обязательно сценарий «все или ничего». Он имеет понятие схемы, и вы храните данные в таблицах в виде строк с первичными ключами. Он имеет язык запросов, CQL, который хорошо знаком с SQL (но гораздо более ограниченным). Знакомство, схема, производительность, настраиваемая согласованность ... довольно приятная комбинация.

Есть недостатки. НЕТ присоединений. Таким образом, вам нужно больше сосредоточиться на моделировании данных и узнать типы запросов, которые вам понадобятся для работы в режиме реального времени. Модель концептуальных данных, вероятно, будет отличаться от реальной модели физических данных. Вероятно, у вас есть некоторая информация (то есть концептуальные данные) как копии в денормализованных физических таблицах. Это приводит к очень быстрой производительности, но вам нужно немного понять ваши данные.

Для аналитических запросов вы обычно соединяете его с Spark. Это позволит вам запросить ваш набор данных, как Hadoop. Запросы медленнее, чем в реальном времени, но могут обеспечить хороший баланс общего объема данных и гибкость запросов.

Cassandra сам по себе НЕ будет полнотекстовой поисковой системой. Однако, это не редкость, чтобы связать его с Lucene или Solr, чтобы предоставить возможности поиска.

С точки зрения использования, Cassandra может использоваться во многих формах. В самом простом случае это ключевое хранилище значений, где каждое значение представляет собой набор упорядоченных пар значений ключа. Ключевое значение верхнего уровня дает вам разделы (осколки) данных. Это позволяет эффективно хранить данные временных рядов. «Ценности» поддерживают также сбор столбцов наборов, карт и списков, и вы можете иметь «точные соответствия индексов» на них. Это позволяет немного более гибкий запрос. Эти функции означают, что Cassandra можно использовать для самых разных вариантов использования, но, очевидно, не для всех. Это будет действительно зависеть от того, какой вариант использования вы пытаетесь решить. Там нет единой «лучшей базы данных NOSQL». Каждое хранилище данных имеет набор прецедентов, и трудно отобразить все сопоставления. Вместо этого вам нужно будет посмотреть, какие ваши варианты использования, а затем посмотреть, какие функции магазина перекрываются больше всего, а затем выбрать один или, возможно, больше.

Смежные вопросы