Есть база Log DB, в которую выполняются insert и delete операции. Ниже я приведу основные требования для этой базы. Насколько я понимаю, есть два ограничения, влияющих на ответ на мой вопрос: это какой объем данных нужно хранить и сколько операций в секунду нужно делать.

Каждый день добавляются 72 000 000 записей, что равносильно нагрузке 2000 записей в секунду в течение 10 активных часов дня.
Требуется хранить записи за последние 180 дней, суммарно 13 000 000 000 записей, 30 ТБ (2500 байт на одну запись с учетом Постгрес оверхеда и индексов). Когда начинается новый день, данные за самый старый день должны быть удалены.

Параллельно добавлению другая подсистема выполняет чтение со скоростью 500 селектов/сек:

Вот примерный DDL (синтаксис Оракла) единственной таблицы в этой базе, чтобы была понятна идея, индексы опущены:


Пока планируется использовать недорогое commodity серверное железо. Шардинг мы собираемся делать на уровне приложения, Конфигурация Постгреса планируется Active-standby с числом реплик = 1.

Мое текущее предположение, что PostgreSQL на одном хосте (8 ядер, 16 GB RAM, 2 x 4 TB SSD) сумеет обработать как минимум 10 000 insert-ов в секунду. И что понадобятся 8 хостов или виртуальных машин с такими параметрами.
Расчет такой: 30 ТБ * 2 (replication factor) / 8 ТБ (размер дисков на хосте) = 8 хостов. Т.е. будет 4 хоста-шарда и 4 хоста-реплики для этих шардов.
Пожалуйста, покритикуйте это утверждение.

Maxim Boguk, LeXa NalBat, спасибо за советы.

Maxim Boguk1) Я бы памяти доставил до 64GB.
ок
Maxim Boguk2)Тоже надо будет подневное партиционирование конечно.
это да
Maxim Boguk3)Объем дисков вы совсем впритык взяли, возможно стоит сразу на 5 шардов делать (или доставлять больше дисков на 1 шард).

ок
Maxim Boguk4)Подумал бы о том чтобы читающие запросы на реплики завернуть.

да, хорошая идея

Maxim BogukPS: учитывая что 80% цены железа у вас на SSD получаются я бы скорее взял 2U сервера на 24 2' дисковых слота каждый (у supermicro таких платформ - пачка), и сделать на них raid6 из тех же SSD, это может оказаться выгоднее и проще в администрировании.

сколько бы 2U серверов вы бы предложили, сколько SSD дисков какого объема на каждом? Зачем делать RAID6? Ведь это потребует как минимум 4 дисков на хосте. RAID6 переживает падение двух дисков одновременно. Зачем такая перестраховка? Я планировал обойтись вообще без RAID, а защиту от падений дисков сделать на уровне Postgres репликации.

LeXa NalBatМне это кажется достаточно оптимистичной оценкой. У нас сейчас данные вставляются в базу статистики на сервер с SSD дисками командой COPY со скоростью 5К row/sec (ширина строки 100 байт, три индекса коррелированных со входными данными, триггер for each row). Но вставка фактически выполняется в один поток, поэтому предельно возможная скорость могла бы быть большей.

Вот это интересно. Можете сказать, сколько у вас ядер какой частоты на сервере, сколько памяти, какие именно и сколько штук на хосте SSD? И сколько записей всего в базе?

LeXa NalBatЕсть важный момент. При вставке текущих данных естественным образом, то есть в порядке возрастания F_RECORD_TIME, скорость вставки уменьшается линейно при наличии индексов, которые начинаются с (F_RECORD_TIME,..). Однако, индексы, начинающиеся с других полей (F_EXTERNAL_ID, F_SCOPE, F_GROUP_TAG, F_STATUS,..), не коррелирующих с F_RECORD_TIME, могут кардинально замедлить вставку. Я наблюдал это, правда при тестировании прототипа на HDD дисках

Хм, почему скорость вставки уменьшается линейно? Вроде как сложность вставки в рендж индекс O(log(n)), не O(n).

Maxim Boguk2 сервера... мастер и реплику... на 40-50TB SSD raid6 в каждом. Если вы ведете речь о 4TB ssd то в raid6 на 24 слота можно набрать до 80Tb что вам с головой и даже еще заранее 2-4 ssd hotspare оставить.
Я как то прикидывал в аналогичной ситуации - такая схема получается раза в 2 дешевле по железу чем предлагаемый вам шардинг (если не больше чем в 2). И заодно на хостинге сэкономите (так как он per unit считается) и на overhead На администрирование 10 серверов вместо 2х. Плюс даже выход 2х дисков из строя на сервере - его не убьет (а на шардинге у вас RAID0 получается что вообще схема стремная для базы).

Понятно. А 1 сервер потянет 2000 инсертов/сек и 500 селектов/сек? (я помню про ваше предложение читать с реплики, но здесь рассматриваю случай, когда один хост упал)
Какой вообще предел TPS для одного сервера, если мы говорим не про диски (обращения к ним параллелятся, если их 24 штуки), а про CPU и RAM ?

LeXa NalBatОбъем месячной партиции составляет 2.9 Тб (в том числе три индекса занимают 1.6 Тб). В партиции содержится порядка 5-10 млрд строк, точнее сказать не могу, статистика неполная.

Я правильно понимаю, что у вас около 20 месячных партиций по 2.9 ТБ?

LeXa NalBat, Maxim Boguk,
спасибо за советы. Ваши живые примеры с реальными цифрами многое проясняют.

Maxim BogukТак как одно дело отдать 1 строку по PK а совсем другое миллион строк по сложным условиям.
Но вообще разумные пределы для одного сервера это будет порядка 50.000 insert/s (но это требует очень внятной настройки и понимания что делаешь, 10.000 insert/s - совсем легко), и наверное до 300.000-500.000 простых select/second.
Предполагается что у сервера есть разумное количество ядер конечно (т.е. 24-64 без учета HT).


Речь про простые селекты, которые возвращают несколько записей, 10-20.
Допустим, это будет 50 К селектов/сек.
Какая будет летенси этих запросов? Другими словами, сколько тредов приложения понадобится, чтобы держать 50 К селектов/сек ?

И еще вопрос: допустим, есть другая база, в одну из таблиц которой нужно добавить столбец и заполнить его значением, которое зависит от двух других столбцов отдельно взятой строки.
Если размер базы составляет 600 М записей, каждая строка занимает 300 байт с учетов всех оверхедов и индексов, какой порядок времени (минуты, часы, дни) займет выполнение операции ALTER TABLE T_1 ADD COLUMN F_NEW_COLUMN?
Какой порядок времени займет выполнение операции UPDATE T_1 SET F_NEW_COLUMN = F_1 + "_" + F_2, если такое вообще возможно сделать за один раз?