5 узлов m4.large Instances против m4.2xlarge RDS - PullRequest
0 голосов
/ 14 сентября 2018

Я задаю этот вопрос, чтобы узнать мнение об услугах Amazon.

В настоящее время я использую RDS на экземпляре m4.2xlarge, но у меня возникают проблемы с производительностью в больших базах данных. Поэтому я решил изучить Big Data. Я думаю начать использовать hadoop с 5 инстансами Amazon m4.large или m4.xlarge.

Есть ли у кого-нибудь подобный опыт или совет по этому вопросу?

Ответы [ 2 ]

0 голосов
/ 14 сентября 2018

Джон Хэнли прав, RDS и Hadoop очень разные звери.Вопрос в том, с какими типами данных вы работаете?

Если данные и ваши варианты использования по своей природе являются реляционными (внешние ключи, индексы, ограничения уникальности, транзакции ACID, необходимость в эффективных объединениях и произвольных запросах)) тогда вам лучше всего использовать базу данных SQL «webscale» - в этом случае я бы рекомендовал взглянуть на Amazon Aurora.Это замена для MySQL или PostgreSQL с гораздо лучшей производительностью и масштабируемостью.

Если ваши данные в некотором роде реляционные, но ваш вариант использования больше подходит для бизнес-аналитики (схемы «звезда / снежинка», столбчатые агрегации,произвольные детализации), и вы меньше зависите от задержки записи, вам, вероятно, лучше использовать хранилище данных, такое как Redshift.

Если ваши данные более похожи на таблицы поиска, а большая часть ваших запросов - точечные запросыв большое пространство имен (например, GUID, cookie-идентификаторы, идентификаторы устройств, такие как IDFA), тогда вам, вероятно, понадобится хранилище Key-Value - DynamoDB будет очевидным выбором для AWS, хотя для некоторых рабочих нагрузок (и наборов данных меньше, скажем, скажем,, 100 ГБ) вы также можете рассмотреть Redis в ElastiCache.

Если ваши данные больше похожи на события - скажем, вы храните показы баннеров или сообщения IoT - тогда вам, вероятно, нужен стек, который позволяет вам получать данныеновые данные в реальном времени;Друид или HBase + Phoenix могут быть здесь ответом, если не выделенной базой данных временных рядов.

И, наконец, если ваши данные велики и ваш общий случай использования включает сложные и произвольные (не рассчитанные заранее) запросы с высоким-Терабайты или петабайты данных, тогда Hadoop станет отличным вариантом, так как гораздо дешевле хранить ваши данные на S3 и раскручивать кластеры EMR по мере необходимости, чем запускать оборудование, необходимое для хранения данных встек базы данных или хранилища данных.Если вы идете по этому пути, вы часто можете получить очень значительное повышение производительности, сохраняя ваши данные в столбчатом формате (например, Parquet) на диске и запрашивая их с помощью чего-то вроде Spark SQL или Presto (Athena на AWS).Однако, как только вы переключитесь на этот вид «чистого» большого стека данных, вы окажетесь на территории OLAP, что означает, что вы, вероятно, смотрите на время запроса в минутах или часах, а не в миллисекундах и секундах, так что об этом следует знать.

0 голосов
/ 14 сентября 2018

Hadoop и RDS очень разные технологии и не являются взаимозаменяемыми.

RDS обеспечивает очень быструю обработку транзакций (OLTP).Hadoop больше ориентирован на пакетную обработку (OLAP).С появлением Spark эта линия движется.Существуют приложения SQL-запросов для Hadoop, но они не заменят базу данных SQL там, где она сильнее всего: сложные запросы, объединения таблиц и т. Д.

В некоторых случаях данные слишком велики для традиционных серверов SQL.Я бы посмотрел на Redshift в этот момент.Вам придется переосмыслить, как хранятся ваши данные, формат запроса и т. Д.

Вы не предоставили подробную информацию об областях производительности, которые вызывают у вас проблемы.Для проблем чтения, посмотрите на масштабирование шире (чтение-реплики).Для проблем с записью вам нужно масштабировать больше (больше / быстрее, быстрее, больше памяти и т. Д.).В некоторых случаях простая оптимизация ваших запросов может иметь существенные последствия.

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

...