Hadoop (+ HBase / HDFS) против Mysql (или Postgres) - множество независимых, структурированных данных, которые нужно обработать и запросить

Question

Привет в SO ,

Я хотел бы получить несколько идей / комментариев от вас, уважаемая и почтенная группа.

У меня есть 100M записей, которые янужно обрабатывать.У меня есть 5 узлов (в группе камней), чтобы сделать это.Данные очень структурированы и хорошо подходят для реляционной модели данных.Я хочу делать что-то параллельно, так как моя обработка занимает некоторое время.

На мой взгляд, у меня есть два основных варианта:

Установить mysql на каждом узле и поставить 20M записей на каждом.Используйте головной узел для делегирования запросов узлам и агрегирования результатов. Возможности запросов ++ , но я могу рискнуть испытать некоторые головные боли, когда приду к выбору стратегии разделения и т. Д. (В. Это то, что они называют кластером mysql / postgres?).Действительно плохая часть заключается в том, что теперь обработка записей остается на мое усмотрение (как распределять между машинами и т. Д.) ...

В качестве альтернативы установите Hadoop, Hive и HBase (обратите внимание, что это можетне самый эффективный способ хранения моих данных, так как HBase ориентирован на столбцы) и просто определение узлов.Мы пишем все в парадигме MapReduce и, блин, мы живем долго и счастливо.Проблема здесь в том, что мы теряем возможности запросов «в реальном времени» (я знаю, что вы можете использовать Hive, но это не рекомендуется для запросов в реальном времени - что мне нужно) - поскольку у меня также есть несколько обычных запросов sql для выполнения время от времени »выберите * из вина, где color = 'brown' ".

Обратите внимание, что теоретически - если бы у меня было 100M машин, я мог бы сделать все это мгновенно, поскольку для каждой записи обработка не зависит от другой.Кроме того - мои данные только для чтения.Я не предполагаю никаких обновлений.Мне не нужно / хочу 100M записей на одном узле.Я не хочу, чтобы там были избыточные данные (поскольку их много), поэтому храните их в ОБА mysql / postgres и Hadoop / HBase / HDFS.это не реальный вариант.

Большое спасибо

Answer 1

Можете ли вы доказать, что MySQL является узким местом?100M записей не так много, и похоже, что вы не выполняете сложные запросы.Не зная точно, что это за обработка, вот что я бы сделал в следующем порядке:

1. Сохраните 100M в MySQL.Взгляните на утилиту Cloudera Sqoop, чтобы импортировать записи из базы данных и обрабатывать их в Hadoop.
2. Если MySQL является узким местом в (1), рассмотрите возможность настройки ведомой репликации, которая позволит вам распараллеливать чтения безсложность защищенной базы данных.Поскольку вы уже заявили, что вам не нужно возвращаться в базу данных, это должно быть жизнеспособным решением.Вы можете реплицировать свои данные на столько серверов, сколько необходимо.
3. Если вы выполняете сложные запросы на выборку из базы данных, и (2) все еще не жизнеспособны, то подумайте об использовании Sqoop для импорта ваших записей и выполнения любого запросапреобразования, которые вам нужны в Hadoop.

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

Answer 2

Есть несколько вопросов, прежде чем предлагать.
Можете ли вы сформулировать свои запросы для доступа только по первичному ключу? Другими словами - если вы можете избежать всех объединений и сканирования таблицы. Если так - HBase является опцией, если вам нужен очень высокий уровень доступа для чтения / записи.
Я не думаю, что Hive - хороший вариант, учитывая небольшой объем данных. Если вы ожидаете, что они значительно вырастут - вы можете рассмотреть это. В любом случае Hive подходит для аналитических рабочих нагрузок, а не для обработки OLTP.
Если вам нужна реляционная модель с объединениями и сканированиями - я думаю, что хорошим решением может быть один главный узел и четыре подчиненных с репликацией между ними. Вы будете направлять все записи в мастер, а баланс - среди всего кластера. Это особенно хорошо, если у вас гораздо больше чтения, чем записи.
В этой схеме вы будете иметь все 100M записей (не совпадающих) на каждом узле. Внутри каждого узла вы можете использовать разбиение, если это необходимо.

Answer 3

Вы также можете рассмотреть возможность использования Кассандра . Недавно я обнаружил эту статью на HBase vs. Cassandra , о которой мне напомнили, когда я прочитал ваш пост.

Суть его в том, что Cassandra - это легко масштабируемое решение NoSQL с быстрым запросом , что похоже на решение, которое вы ищете.

Итак, все зависит от того, нужно ли вам поддерживать реляционную модель или нет.

Answer 4

HI

У меня была ситуация, когда у меня было много таблиц, которые я создавал параллельно, используя sqlalchemy и многопроцессорную библиотеку python. У меня было несколько файлов, по одному на таблицу, и я загрузил их, используя параллельные процессы копирования. Если каждый процесс соответствует отдельной таблице, это работает хорошо. С одной таблицей использование COPY будет затруднено. Я думаю, вы можете использовать разбиение таблиц в PostgreSQL. Если вы заинтересованы, я могу дать более подробную информацию.

Привет.