Не уверен, что это правильная группа для моих запросов, но я должен был быть уверен в том, что я собираюсь купить. Я уже провел свое исследование и пока не уверен в этом, так как я делаю это впервые. Я планирую разместить свой собственный настольный сервер и решил использовать процессор XEON с как минимум 8 ядрами и 32 ГБ оперативной памяти. Но я не уверен, что это правильный домашний сервер для меня. Мое приложение должно обрабатывать не менее 20 000 000 SQL-запросов в час, и в нем есть критически важные процессы, которые должны быть максимально быстрыми.
1 ответ
3
Есть несколько соображений, которые вы должны принять во внимание (и которые не очевидны из вашего поста). Они включают -
Вам нужно как можно больше оперативной памяти - в идеале, чтобы вместить весь набор данных в памяти.
Если вы выполняете значительное количество операций записи и / или ваши данные не могут полностью поместиться в память, вам нужен самый быстрый диск, который вы можете получить - я не знаю размер вашего набора данных, но твердотельные накопители RAIDED PCI-E хорошая идея - когда вы говорите о том, что это "критически важно". Да, это нормально, чтобы разместить базу данных на SSD - просто бюджет, чтобы заменить их каждые 5 лет или около того.
Вы упомянули "настольный сервер". Я не верю, что этот термин существует - это либо рабочий стол, либо рабочая станция, либо сервер. Я ожидаю, что вы имеете в виду сервер в том, что было известно как корпус / форм-фактор настольного компьютера - если это так, я бы предложил что-то, что будет соответствовать его стороне в 4u - что довольно легко найти, если вы знаете, чтобы посмотреть для этого. Конечно, в большинстве корпусов для настольных ПК имеется только 1 блок питания - что может быть проблемой для надежности и времени безотказной работы - критически важные серверы обычно имеют 2 блока питания на 2 разных фазах.
Большое количество (более медленных ядер), вероятно, лучше, чем менее быстрых, однако это будет зависеть от вашей базы данных и даже от типа запросов (например, Postgres 9.5 не будет разбивать один сложный запрос между несколькими ядрами - переход на Postgres 9.6 сделал, давая почти линейное увеличение скорости на некоторых отдельных запросах с большим количеством ядер - так проверьте вашу базу данных). Точно так же вам следует обратить внимание на разделение базы данных, чтобы это не было узким местом и вы можете развернуть дополнительные серверы по мере необходимости.
Если его задача критически важна, вам также необходимо учитывать репликацию - и как только вы идете по этому маршруту, может иметь (или может не иметь) смысл иметь один сервер, выполняющий чтение-запись, а другой - подчиненный только для чтения - и модифицирующий ваш приложение, чтобы воспользоваться этим. Опять же - мне интересно, было ли слово "критическая миссия" правильным для описания вашего использования.
Как в стороне - нужно учитывать "Расплавление" и его производительность. Производительность базы данных может понизиться на 20-30%, если вы добавите меры по ее снижению. Если вы не смягчаете это - вам нужно знать об этом и управлять рисками (т.е. вдвойне убедитесь, что на нем невозможно выполнить произвольный код - включая обеспечение того, что нет способа выполнить атаку SQL-инъекцией)
Несмотря на то, что говорили другие, если ваши запросы достаточно просты, 5000 запросов в секунду выполнимо - см. Https://www.percona.com/blog/2017/01/06/millions-queries-per-second-postgresql-and- MySQL-мирное-бой-на-современных требовательных рабочих нагрузок /