Вопрос дизайна базы данных относительно производительности

Question

Мне нужна помощь в выборе подхода к проектированию БД.Мы создаем инструмент перевода с использованием Hanami (веб-фреймворк Ruby) и, следовательно, ROM.Мы сталкиваемся с проектным решением иметь одну таблицу DB (Postgresql) для записей перевода, где каждая запись предназначена для одной комбинации исходного и одного целевого языка.Однако источником и целью может быть любой язык: EN-DE, FR-EN.

Другая возможность - таблица БД для каждой языковой пары.

В настоящее время у нас имеется около 1 500 000 устаревших записей.,Мы не достигнем 2.000.000 в ближайшее время, но, тем не менее, нам нужно это рассмотреть.

Мы склонны к первому варианту, но будет ли он осуществимым с точки зрения запросов и производительности?Основным отличием является то, что для первого варианта сначала должны запрашиваться соответствующие языки, а затем запускается запрос соответствующей строки перевода.

Будет ли существенное различие в производительности для обоих вариантов?

Спасибо

себа

Answer 1

Первый подход будет наиболее гибким, поскольку в будущем вы сможете добавлять языковые комбинации без изменений схемы.Второй подход будет означать, что вы добавляете таблицу для каждой языковой комбинации, которая будет одновременно кошмаром обслуживания и сложным кодом для запроса нескольких таблиц (что также может означать динамические запросы, приводящие к низкой производительности)

PostgreSQL должен иметь возможностьобрабатывать 1500000 записей, как на одном дыхании, при условии, что у вас достаточно оборудования и выполнены правильные настройки производительности.Я работал с таблицами PostgreSQL с 50 миллионами строк, и он хорошо работает.

Answer 2

Вы можете нормализовать свою схему БД и избежать лишних данных.

Во многих случаях удобно иметь несколько маленьких таблиц вместо одной огромной таблицы.Но это зависит от нашей системы, и единого возможного решения не существует.

Мы также должны ответственно использовать индексы.Мы не должны создавать индексы для каждого поля или комбинации полей, поскольку, хотя нам не нужно перемещаться по всей таблице, мы используем дисковое пространство и добавляем накладные расходы для операций записи.

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