Какая база данных подходит для работы? - PullRequest
1 голос
/ 19 августа 2011

Я работаю над функцией и могу использовать мнения о том, какую базу данных мне следует использовать для решения этой проблемы.

У нас есть приложение Rails, использующее MySQL. У нас нет проблем с MySQL, и он работает отлично. Но для новой функции мы решаем, оставаться MySQL или нет. Чтобы упростить задачу, предположим, что есть модели User и Message. Пользователь может создавать сообщения. Сообщение доставляется другим пользователям на основании их связи с постером.

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

Следовательно, сообщение может выглядеть так:

{
  id: 1,
  message: "Hi",
  created_at: 1234567890,
  metadata: {
    user_id: 555,
    category_1: null,
    category_2: null,
    category_3: null,
    ...
  }
}

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

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

Лично у меня есть опыт работы с MySQL и MongoDB. Я начал исследования Cassandra, HBase, Riak и CouchDB. Я мог бы получить помощь от людей, которые могли бы провести исследование относительно того, какая база данных подходит для моей задачи.

И да, таблица сообщений может легко превратиться в миллионы или строки.

Ответы [ 6 ]

4 голосов
/ 19 августа 2011

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

У меня есть опыт работы с MongoDB.Это ужасный выбор, если вы не хотите тратить много времени, пробуя разные вещи и понимая, что они не работают.После небольшого увеличения вы в основном не сможете использовать такие вещи, как вторичные индексы, обновления и другие вещи, которые делают Mongo отличным в остальном инструментом (в основном это связано с его глобальной блокировкой записи и форматом базы данных на диске).по сути, отстой в параллелизме и фрагментах очень легко, если вы удаляете данные).

Я не согласен с тем, что о HBase не может быть и речи, у него нет вторичных индексов, но вы все равно не сможете их использовать один разВы превышаете определенную нагрузку.То же самое относится и к Cassandra (с которой проще работать и работать, чем с HBase).По сути, вам придется реализовать свою собственную индексацию, какое бы решение вы ни выбрали.

Что вам следует учитывать, так это то, что если вам нужна согласованность по доступности или наоборот (например, насколько это плохо, если сообщение потеряно илизадержка и насколько плохо, если пользователь не может публиковать или читать сообщение), или если вы будете обновлять свои данные (например, данные в Riak - это непрозрачный блоб, чтобы изменить его, вам нужно прочитать его и написатьназад, в Cassandra, HBase и MongoDB вы можете добавлять и удалять свойства без предварительного чтения объекта).Простота использования также является важным фактором, и Mongo, безусловно, прост в использовании с точки зрения программиста, а HBase ужасен, но просто потратьте некоторое время на создание своей собственной библиотеки, которая инкапсулирует неприятные вещи, это того стоит.

Наконец, не слушайте меня, попробуйте их и посмотрите, как они работают и каково это.Убедитесь, что вы пытаетесь загрузить его как можно сильнее, и убедитесь, что вы тестируете все, что будете делать.Я сделал ошибку, не проверяя, что происходит, когда вы удаляете много данных в MongoDB, и дорого заплатил за это.

3 голосов
/ 19 августа 2011

Я думаю, что вы точно храните метаданные вместе с каждым сообщением!Вероятно, стоит пожертвовать хранилищем для более быстрого поиска.Обратите внимание, что это может осложниться, если вам когда-нибудь понадобится изменить метаданные пользователя и распространить их на все сообщения.Вы должны подумать, как часто это может происходить, нужно ли вам на самом деле обновлять все записи сообщений, и исходя из этого, стоит ли платить цену ради меньшего количества запросов (это, вероятно, того стоит, но это зависит от того,особенности вашей системы).

Я согласен с @Andrej_L, что Hbase не является правильным решением этой проблемы.Кассандра соглашается с этим по той же причине.

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

Riak был бы намного лучшим вариантом, так как он запрашивает ваши данные с помощью map-Reduce.Это позволяет вам создавать любые запросы без предварительной индексации всех ваших данных, как на диване.Миллионы строк не являются проблемой для Риака - не стоит беспокоиться.Если возникает необходимость, он также очень хорошо масштабируется, просто добавляя больше узлов (и он также может сбалансировать себя, так что это действительно не проблема).

Так что, основываясь на моем собственном опыте, я бы порекомендовалRiak.Однако, в отличие от вас, у меня нет непосредственного опыта работы с MongoDB, поэтому вам придется судить об этом самому Риаку (или, может быть, кто-то другой может ответить на этот вопрос).

3 голосов
/ 19 августа 2011

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

Я думаю, что в этом сценарии лента изменений CouchDB может оказаться весьма полезной, хотя вам, вероятно, также придется создавать более сложные представления на основе запроса метаданных сообщения.Если скорость критична, попробуйте также взглянуть на redis , который действительно быстр и имеет функциональность pub / sub .MongoDB с поддержкой специальных запросов также может быть хорошим решением для этого варианта использования.

2 голосов
/ 19 августа 2011

Из моего опыта работы с Hbase не очень хорошее решение для вашего приложения.Потому что:

  1. По умолчанию не содержит вторичного индекса (вы должны установить плагины или что-то подобное).Таким образом, вы можете эффективно искать только по первичному ключу.Я реализовал вторичный индекс, используя hbase и дополнительные таблицы.Таким образом, вы не можете использовать это в онлайн-приложении, потому что для получения результата вы должны запустить карту / уменьшить задание, и это займет много времени для миллионов данных.

  2. Очень трудно поддерживатьи отрегулируйте эту базу данных.Для эффективной работы вы будете использовать HBAse с Hadoop, а для этого нужны мощные компьютеры или несколько.

  3. Hbase очень полезен, когда вам необходимо создавать сводные отчеты по большому количеству данных.Кажется, вам не нужно.

1 голос
/ 06 декабря 2011

Riak может запрашивать так быстро, как вы делаете, зависит от узлов

Mongo позволит вам создать индекс для любого поля, даже если это массив

CouchDB очень отличается, он строит индексы, используя хранимое Map-Reduce (но без уменьшения), которое они называют «представлением»

RethinkDB позволит вам иметь SQL, но немного быстрее ТокуДБ тоже будет

Redis убьет всех на скорости, но он целиком хранится в оперативной памяти

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

1 голос
/ 19 августа 2011

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

Звучит таквам нужно объединение, так что вы в основном можете забыть о CouchDB, пока они не разберут код, который работал над многовидовым представлением (на самом деле не уверен, что он все еще работает).

...