Чи реально встановити на PostgreSQL базу даних на 100 ТБ (фактично близько 90 ТБ) без різкості даних між кількома вузлами? Чи є історії / приклади успіху щодо подібних налаштувань?
Відповіді:
50K пише в секунду, що їх потрібно поглинати, як правило, більше, ніж виклик. Навіть у синтетичних тестах із досить простими вставками, обмеження PostgreSQL мають тенденцію до приблизно 10 К / с - і там ви навіть не маєте такого великого звіра щодо розміру бази даних.
Також система вводу / виводу для цього одного вузла PostgreSQL буде цікавою, як навіть для RAID 10, і якщо припустити, що 50K вставок буде дорівнювати лише 50K IOPS (що, мабуть, неправильно, але це залежить від вашої схеми бази даних та індексів ), вам знадобиться приблизно сто дисків, поєднаних з дуже хорошим масивом, що дозволяє заощадити від придбання декількох сотень дисків для своєчасного обслуговування запису.
Якщо заточування легко, і ви очікуєте такого величезного навантаження для запису, тоді перейдіть до шардингу. Записи можуть бути дуже важкими для масштабування.
Це реально і буде працювати. Продуктивність більшою мірою залежить від обсягу оперативної пам’яті. Чим більше оперативна пам'ять, тим більше кеш-пам'ять і тим довше PostgreSQL може кешувати дані перед завантаженням на диск.
PostgreSQL записуватиме дані в кеш і час від часу завантажувати кеш. Таким чином, 50 К ВСТАВЛЕННЯ за секунду не буде переведено на 50 К IOPS. Це буде набагато менше, тому що він буде кластеризувати записи разом і записувати їх все одночасно.
Велика база даних не є проблемою, якщо більшість робіт INSERT. PostgreSQL доведеться змінювати індекси тут і там, але це справді проста робота. Якщо у вас було багато SELECT в базі даних такого розміру, вам дійсно потрібно було б осколити.
Колись я працював над Oracle DB (Oracle 10g) з 400 ТБ на 16 ГБ сервері, лише один екземпляр. Навантаження на базу даних теж була первинною ВСТАВЛЕННЮ, тож декілька SELECT в день і мільйони INSERT щодня. Продуктивність була далеко не проблемою.
У 100TB у вас є деякі важливі проблеми. Буде це працювати для вас чи ні, залежить від того, як ви хочете їх вирішити.
Вам потрібні достатні способи поглинання навантаження на запис. Це залежить від завантаження запису. Але при достатньому дивовижному зберіганні це можна вирішити. Тут швидкість - велика проблема. Аналогічно читати доступ слід уважно.
Більшість баз даних не складаються з маси невеликих таблиць, але часто мають одну-дві дійсно великі, які можуть становити до половини розміру db. PostgreSQL має жорсткий ліміт - 32 ТБ на стіл. Після цього тип одиниці закінчується лічильниками сторінок. Це можна вирішити за допомогою спеціальної збірки PostgreSQL або розділення таблиць, але це серйозна проблема, яку потрібно вирішити спочатку.
PostgreSQL має реальні обмеження в кількості оперативної пам’яті, яку він може використовувати для різних завдань. Тож наявність більшої оперативної пам’яті може або не допоможе вам за певний момент.
Резервні копії .... Резервні копії цікаві в такому масштабі. 60TB db, про який я знаю, мусив використовувати резервні копії знімків fs, а потім підробляти резервні копії для бармена для архівації Wal. Ці підроблені резервні копії були проксі-сервера для резервного копіювання знімків. Як я вже сказав: "Вони не підроблені резервні копії. Вони альтернативні резервні копії!"
Є люди з базами даних, що наближаються до цього діапазону. Я зустрів принаймні одну особу, яка працювала в банку в Нідерландах, який мав базу даних PostgreSQL 60 Тб. Однак це насправді, насправді залежить від вашої завантаженості та розміру сама по собі не проблема.