Вопрос проектирования базы данных относительно производительности
Мне нужна помощь в выборе подхода к проектированию БД. Мы создаем инструмент перевода с помощью Hanami (веб-фреймворк Ruby) и, следовательно, ROM. Перед нами стоит проектное решение о наличии одной таблицы БД (Postgresql) для записей переводов, где каждая запись предназначена для одного исходного и одного целевого языков. Однако исходный и целевой могут быть на любом языке: EN-DE, FR-EN.
Другой вариант - это таблица БД для каждой языковой пары.
В настоящее время у нас есть около 1.500.000 старых записей. В ближайшее время мы не достигнем 2 000 000, но все же это необходимо учитывать.
Мы склоняемся к первому варианту, но будет ли он осуществим с точки зрения запросов и производительности? Основное отличие состоит в том, что для первого варианта необходимо сначала запросить соответствующие языки, а затем инициировать запрос соответствующей строки перевода.
Будет ли разница в производительности между обоими вариантами?
Спасибо
себа
2 ответа
Первый подход будет наиболее гибким, так как в будущем вы сможете добавлять языковые комбинации без изменения схемы. Второй подход означал бы, что вы добавляете таблицу для каждой языковой комбинации, что было бы кошмаром обслуживания и сложным кодом для запроса нескольких таблиц (что также может означать динамические запросы, приводящие к низкой производительности)
PostgreSQL должен уметь обрабатывать 1500000 записей, как ветер, при условии, что у вас достаточно оборудования и вы выполнили правильную конфигурацию производительности. Я работал с таблицами PostgreSQL с 50 миллионами строк, и они работают хорошо.
Вы можете нормализовать схему БД и избежать избыточных данных.
Во многих случаях удобно иметь несколько маленьких столиков вместо одной огромной. Но это зависит от нашей системы, и нет единого возможного решения.
Мы также должны ответственно использовать индексы. Нам не следует создавать индексы для каждого поля или комбинации полей, поскольку, хотя нам не нужно перемещаться по всей таблице, мы используем дисковое пространство и добавляем накладные расходы для операций записи.
Еще один очень полезный инструмент - это управление пулом соединений. Если у нас есть система с большой нагрузкой, мы можем использовать это, чтобы избежать перегрузки соединений в базе данных и иметь возможность повторно использовать их.