MongoDB или Cassandra лучше, чем MySQL, для больших наборов данных? - PullRequest
6 голосов
/ 15 декабря 2011

В нашей (в настоящее время MySQL) базе данных более 120 миллионов записей, и мы часто используем сложные запросы JOIN и логику уровня приложения в PHP, которые касаются базы данных. Мы - маркетинговая компания, которая в первую очередь занимается интеллектуальным анализом данных, поэтому у нас есть много больших отчетов, которые нужно запускать ежедневно, еженедельно или ежемесячно.

Одновременно служба поддержки клиентов работает на реплицированном ведомом устройстве той же базы данных.

Мы хотели бы, чтобы эти отчеты создавались в Интернете в режиме реального времени, а не создавали для них электронные таблицы вручную. Однако во многих наших отчетах для извлечения данных требуется значительное время (в некоторых случаях более часа).

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

Учитывая все это, каков наш лучший вариант для базы данных?

Ответы [ 3 ]

11 голосов
/ 15 декабря 2011

Я думаю, что вы ошибаетесь в этой проблеме.

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

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

Какие у вас варианты?Вам нужно масштабировать настройки вашего сервера и программного обеспечения (что в любом случае вам придется делать с любым NoSQL, в какой-то момент подключитесь к более быстрым жестким дискам).Вы также можете захотеть взглянуть на альтернативные механизмы хранения (кроме MyISAM и InnoDB - например, один из лучших механизмов, которые, по-видимому, переводят случайный ввод-вывод в последовательный ввод-вывод, - TokuDB ).

Внедрение более быстрой подсистемы жесткого диска также поможет вашим потребностям ( FusionIO , если у вас есть ресурсы для ее получения).

Без дополнительной информации с вашей стороны (чтонастройка сервера, то, какую версию MySQL вы используете, и какие механизмы хранения + размеры данных вы используете), все это предположение.

9 голосов
/ 15 декабря 2011

Кассандре по-прежнему нужен Hadoop для MapReduce, и MongoDB имеет ограниченный параллелизм в отношении MapReduce ...

... так что ...

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

Если вы предоставите больше информации о вашем кластере, мы можем помочь вамлучше.«NoSQL» сам по себе не является решением вашей проблемы.

5 голосов
/ 26 мая 2012

Несмотря на то, что я не являюсь поклонником MySQL, когда ваши данные становятся большими, я должен сказать, что вам далеко не нужно переходить на решение NoSQL.120M строк не так уж и много: база данных, с которой я сейчас работаю, имеет ~ 600M в одной таблице, и мы эффективно запрашиваем ее.Управление таким большим количеством данных с точки зрения ops является проблемой;Запрашивать это не нужно.

Все дело в правильных индексах и их правильном использовании при объединении, а также в настройках памяти.Найдите свои медленные запросы (mysql медленный журнал запросов FTW!) И научитесь использовать ключевое слово объяснение , чтобы понять, почему они медленные.Затем настройте свои индексы, чтобы ваши запросы были эффективными.Кроме того, убедитесь, что вы понимаете настройки памяти MySQL.В документах есть отличные страницы, объясняющие, как они работают, и их не так сложно понять.

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

Решения NoSQL, такие как Cassandra, имеют много преимуществ.Кассандра великолепно пишет данные.Масштабировать ваши записи очень просто - просто добавьте больше узлов!Но компромисс заключается в том, что вернуть данные труднее.С точки зрения затрат, если у вас есть опыт работы с MySQl, вероятно, лучше использовать это и масштабировать ваше текущее решение до тех пор, пока оно не достигнет предела, прежде чем полностью переключить вашу базовую архитектуру.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...