Как быстро разделить таблицы SQL на 10 миллиардов строк с помощью AWS?

У меня есть база данных SQL данных, представленных в нормализованном формате, с несколькими таблицами, содержащими несколько миллиардов строк данных. Я решил разделить большие таблицы на отдельные таблицы по itemId, поскольку, когда я запрашиваю данные, меня интересует только один элемент за раз. В итоге после разделения данных у меня было бы 5000+ таблиц. Проблема в том, что разделение данных занимает около 25 минут для построения единой таблицы для 1 элемента.

5000 items x 25 minutes = 86.8 days

Чтобы полностью разбить всю мою базу данных SQL, потребуется более 86 дней. Вся моя база данных составляет около 2,5 ТБ.

Могу ли я использовать AWS для распараллеливания на уровне элементов? Могу ли я использовать сервисы миграции базы данных AWS для размещения базы данных в ее текущей форме, а затем использовать процесс AWS для обработки всех 5000 запросов для разделения больших таблиц на 5000 меньших таблиц с 2 млн строк в каждой?

Если нет, то мне просто нужно добавить больше оборудования, чтобы оно работало быстрее (ЦП или ОЗУ)?

Заранее спасибо.

Если вы используете простой RDS (по общему признанию, разумную машину), правильный ли индекс не работает для всего набора данных? Это немного похоже на Проблема XY в том смысле, что вы придумали решение, а не проблему.

stdunbar 14.06.2018 01:37

Пожалуйста, уточните, что вы имеете в виду. Какова ваша "база данных SQL", это красное смещение? (красное смещение не выполняет внутреннее разбиение), если вы используете спектр красного смещения / афину, вы можете размещать свои данные в сегментах s3, но они обычно могут быть довольно большими. Главное, чтобы конкретизировать то, что вы пытаетесь сделать? какой вариант использования? где сейчас данные и какие проблемы вы пытаетесь преодолеть?

Jon Scott 14.06.2018 09:00

Текущая база данных SQL - это SQL Server 2016. Сценарий использования состоит в том, что извлечение данных для одного элемента из этой таблицы занимает много времени, поэтому я пытаюсь разбить очень большую таблицу на множество таблиц по элементам, поскольку мне всегда нужен только один элемент в время. Когда я говорю «долгое время», я имею в виду несколько минут для запроса, но если я хочу извлечь эти данные для создания полной истории элемента (манипулировать данными), это может занять несколько недель. Если я разделю его по элементам, запрос сократится до миллисекунд вместо минут. Но разбиение на разделы по-прежнему занимает много времени.

quantcoder 14.06.2018 18:49

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

quantcoder 14.06.2018 18:55
ReactJs | Supabase | Добавление данных в базу данных
ReactJs | Supabase | Добавление данных в базу данных
Это и есть ваш редактор таблиц в supabase.👇
Понимание Python и переход к SQL
Понимание Python и переход к SQL
Перед нами лабораторная работа по BloodOath:
2
4
934
3

Ответы 3

Это не похоже на хорошую стратегию. Во-первых, простая арифметика состоит в том, что 10 000 000 000 строк с 5 000 строками на элемент приводят к 2 000 000 секций в таблице.

Предел в Redshift (по умолчанию) - 1000000 разделов на таблицу:

Amazon Redshift Spectrum has the following quotas when using the Athena or AWS Glue data catalog:

  • A maximum of 10,000 databases per account.
  • A maximum of 100,000 tables per database.
  • A maximum of 1,000,000 partitions per table.
  • A maximum of 10,000,000 partitions per account.

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

Чтобы уточнить, это будет 5000 разделов, по 2000000 строк на раздел.

quantcoder 13.06.2018 23:43

@quantcoder. . . Ваша выборочная оценка относится к 5000 строкам, откуда и исходит эта оценка.

Gordon Linoff 14.06.2018 03:38

извините, я имею в виду 5000 itemID, а не строк. Один itemID может ссылаться на несколько миллионов строк в этой таблице. Чтобы быть конкретным, я имею дело с финансовыми данными по компаниям, где 5000 - это количество характеристик, которые у меня есть в моей базе данных. У меня есть исторические данные о более чем 40 000 компаний за более чем 20 лет. Когда я запрашиваю в базе данных одну характеристику для одного момента времени по всем компаниям, это занимает много времени. Если я разбиваю большую таблицу по характеристикам, мои запросы значительно улучшаются. Однако разбиение таблицы по характеристикам все равно занимает 25 минут.

quantcoder 14.06.2018 18:58

@quantcoder. . . Время также обычно используется для разбиения на разделы. Но то, что вы говорите, имеет смысл.

Gordon Linoff 15.06.2018 03:55

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

Если вы установите itemId как SORTKEY в таблице Redshift, то Redshift сможет пропускать блоки, которые не содержат желаемого значения (при использовании WHERE itemId = 'xxx'). Это будет очень эффективно.

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

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

quantcoder 14.06.2018 18:50

Используйте itemid как sortkey и distkey. если таблица правильно настроена vacumm и вы выбрали один itemid, это должно дать хорошие результаты, когда время доступа почти такое же хорошее, как и для отдельной таблицы. distkey используется для распределения данных между шардами, что означает, что блоки каждого идентификатора элемента будут храниться вместе на одном шарде, что ускоряет их извлечение. Наличие идентификатора элемента также sortkey означает, что для идентификаторов элементов с небольшими номерами строк, которые все существуют в одном сегменте, поиск строк в блоках таблицы на сегменте будет максимально быстрым.

Другие вопросы по теме