OEL 7
. DB type — web app
. Number of connections — ~20
. Storage — SSD (если правильно понял)
. How big is your database (in Gb)? — ~1TB данных
. How many percent of your transactions are purely reading? — 5% разраб подумал и стало 50%
. How many replicas do you need? — не знаю, нужна помощь в выборе варианта
. Which backup method are you planning to use? — скорее всего logical, но вопрос открытый
. Can you lose single transactions in case of a crash? — вот тут я не до конца понимаю масшатбы проблемы
. Number of disks? — логический 1
Это уже гораздо лучше. :) > . DB type — web app > Number of connections — ~20 Активные (+ pooling) имеются в виду? Если да, то идеально по производительности — это примерно CPU core / connection, учтите (но в реальности обычно меньше, да). ;) > . Storage — SSD (если правильно понял) Скорее всего, правильно (или, по крайней мере, непонятно, в какое кол-во последовательных commits/s преобразуется "1000 rps, 50% write"). > . How big is your database (in Gb)? — ~1TB данных И они все "горячие"? Если да, то памяти Вы, скорее всего, поставите меньше (тут неплохо бы потестировать примерные сценарии). ;) Если нет — идеально постараться сделать так, чтобы "горячие" данные в память всё-таки помещались. Т.е. прикиньте, исходя из этого. > How many replicas do you need? — не знаю, нужна помощь в выборе варианта А чего Вам нужно добиться? Вы про HA обзорно читали? > Which backup method are you planning to use? — скорее всего logical, но вопрос открытый Но почему?! > Can you lose single transactions in case of a crash? — вот тут я не до конца понимаю масшатбы проблемы Это вопрос про "synchronous_commit" (прочитайте про него), и одновременно, про производительность диска — если Ваш ответ "нет", то диск обязан "тянуть" столько fsync в секунду (или же нужен BBU в RAID). > . Number of disks? — логический 1 А не "логический"? ;)
Обсуждают сегодня