Сканування мільярда рядків у надшвидкій базі даних

Фон

Місцева база даних містить майже 1,3 мільярда унікальних рядків. Кожен рядок опосередковано асоціюється з певною широтою та довготою (місцем розташування). Кожен рядок має штамп дати.

Використовуйте кейс

Проблема полягає в наступному:

1. Користувач встановлює дату початку / закінчення та діапазон значень (наприклад, 100 - 105).
2. Система збирає всі рядки, які відповідають заданій даті, згруповані за місцем розташування.
3. Система виконує визначення локацій, які протягом цих дат мають статистичну ймовірність потрапляння у заданий діапазон значень.
4. Система відображає користувачеві всі відповідні місця.

Це проблема швидкості та масштабу.

Питання

Яка найменш дорога архітектура рішення, яку ви можете собі уявити, яка дозволила б такій системі отримати результати для користувачів за п'ять секунд?

Поточна система

Навколишнє середовище зараз:

• PostgreSQL 8.4 (можливе оновлення; комутація баз даних не є можливою)
• R і PL / R
• XFS
• WD VelociRaptor
• 8 ГБ оперативної пам’яті (Corsair G.Skill; 1,3 ГГц)
• Чотириядерний GenuineIntel 7 (2,8 ГГц)
• Ubuntu 10.10

Можливі оновлення обладнання.

Оновлення - Структура бази даних

Мільярди рядків знаходяться в таблиці, що нагадує:

id | taken | location_id | category | value1 | value2 | value3

• id - Первинний ключ
• прийнято - дата, призначена рядку
• location_id - Посилання на широту / довготу
• категорія - опис даних
• value1 .. 3 - інші значення, які користувач може запитувати

takenКолона , як правило , послідовні дати , в location_id, іноді кожне місце має дані від 1800 до 2010 (близько 77000 місць, багато з них продубльовані , як кожне місце має дані в тому ж діапазоні дат).

Існує сім категорій, і таблиці вже розділені за категоріями (використовуючи дочірні таблиці). Кожна категорія містить ~ 190 мільйонів рядків. Найближчим часом кількість рядків на категорію перевищить мільярд.

Є приблизно 20 000 локацій та 70 000 міст. Місця розташування співвідносяться з містом за широтою та довготою. Призначення кожної локації до конкретного міста означає знаходження меж міста, що не є тривіальним завданням.

Ідеї

Деякі у мене ідеї включають:

• Знайдіть хмарний сервіс для розміщення бази даних.
• Створіть смугу нальоту SSD (чудове відео).
• Створіть таблицю, яка об'єднує всі місця за містами (попередній розрахунок).

Дякую!

Найголовніше - бути абсолютно впевненим, де знаходиться вузьке місце для певної кількості репрезентативних запитів, оскільки ви не можете перемикати бази даних.

Якщо ви робите повне сканування таблиці, вам потрібні відповідні індекси.

Якщо ви чекаєте вводу / виводу, вам потрібно більше пам’яті для кешування (Jeff Atwood нещодавно згадував, що 24 Gb системи були доступні для настільних систем).

Якщо ви зачекаєте на процесорі, вам слід зрозуміти, чи можна оптимізувати ваші розрахунки.

Для цього потрібна чітка DBA-шапка та капелюх Операційної системи, але це варто, щоб переконатися, що ви гавкаєте потрібне дерево.

Як щодо розділення таблиці на кілька фрагментів, розташованих на різних хостах, на основі штампа дати? Це горизонтально масштабується, і поки у вас є достатня кількість коробок, ви можете написати невеликий двигун агрегації поверх цих налаштувань.

Якщо ви бачите, що штамп дати занадто сильно змінюється, ви можете розділити їх за місцем розташування - знову горизонтально масштабованим. (Сподіваємось, вони не додають ще багато широт / довгот!)

Найгірший сценарій - діапазон дат охоплює всі дати у вашій базі даних.

Ви хочете прочитати 1,3 мільярда записів і зробити якийсь аналіз для кожного запису проти введених значень на одній фізичній машині менше ніж за 5 секунд. Результатом можуть бути всі локації або жодні - ви заздалегідь нічого не знаєте.

З огляду на ці параметри, я б сказав, що це неможливо.

Подивіться на ваш жорсткий диск: швидкість максимальної тривалості менше 150 МБ / с. Читання 1,3 мільярда записів займе більше 5 секунд. CPU-мудро, ви не зможете за 5 секунд робити будь-який статистичний аналіз на 1,3 мільярда записів.

Ваша єдина надія (tm :-)) - знайти якусь функцію пошуку на основі значень, введених користувачем, які звузять пошук вниз (на кілька порядків). Ви можете розрахувати цю функцію пошуку в режимі офлайн. Не знаючи більше про точні критерії відповідності, я не думаю, що хтось може сказати вам, як це зробити, але прикладом може бути поділ діапазону значень на якийсь дискретний інтервал і створення пошуку, який дає всі записи в цьому інтервалі. Поки інтервал достатньо малий, ви можете виконати в ньому реальну роботу, наприклад, обрізання записів, які не відповідають введеному користувачем значенням. В основному торговий простір часом.

Можливо, можливо зберегти всі записи (або принаймні важливу частину) в пам'яті. Напевно, не в 8 Гб. Це принаймні усуне частину вводу / виводу диска, хоча навіть пропускна здатність пам’яті може бути недостатньою для перевірки всього за 5 секунд. У будь-якому випадку, це ще одна методика прискорення подібних програм (поєднати з моєю попередньою пропозицією).

Ви згадуєте про використання хмарного сервісу. Так, якщо ви платите за достатню кількість м'язів процесора та IO і розділіть вашу базу даних на багатьох серверах, ви можете змусити / розділити та перемогти її.

Другий коментар rwong до питання: PostgreSQL пропонує відповідні типи та інструменти індексів (GIST-індекси, GIN-індекси, Postgis, Geometrical типи) таким чином, що дані геоданих та дати, пов'язані з датою, повинні шукати за цими критеріями без особливих проблем.

Якщо ваші запити за цими критеріями займають секунди, це, ймовірно, означає, що такі індекси не використовуються. Чи можете ви підтвердити, що ви розслідували їх як слід?

Враховуючи, що ви використовуєте дані PostgreSQL та дані про широту / довготу, вам обов'язково слід використовувати і PostGIS, таким чином ви можете додати просторовий індекс GiST до вашої бази даних, щоб прискорити роботу.

У мене є така таблиця (з 350k рядками) з конфігурацією, значно меншою, ніж у вас (2 ядра і ледь 2 Гб оперативної пам’яті), але пошук займає менше однієї секунди.

Можливо, ви можете зламати реляційну модель, як Essbase, зі своєю архітектурою OLAP: Essbase Wikipedia

Що я маю на увазі - створити одну таблицю на місто, таким чином закінчившись 1000 таблицями. Не одна таблиця, як ви запропонували, але багато. Індексуйте кожну таблицю за датою та місцем розташування. Багато таблиць, багато індексів -> швидше.

Що стосується вашої ідеї знайти хмарний сервіс для розміщення бази даних, ви ще натрапили на SimpleGeo ? Вони просто перерізали стрічку на службі зберігання даних, яка, очевидно, "спеціально налаштована на зберігання та запит даних про місцевості дуже, дуже швидко" - хоча вартість зберігання та запиту на понад мільярд рядків може зробити цей підхід нездійсненним.

вас очікує проїзд велосипеда по шосе. В даний час ви шукаєте рішення тільки для вирішення цієї проблеми, ви не передбачаєте проблеми, що робити, якщо у вас є 2 мільярди записів? Необхідно вирішити масштабність. відповідь - просто використання об'єктних баз даних. наприклад кеш Intersystems

і повірте мені, я не з міжсистем ;-)