Процессоры ЦП Процессы ЦП Процессоры ЦП среднего уровня Процессы ЦП

Question

У меня есть запрос SELECT с множеством условий IF, который я могу выполнить либо в самом запросе (принимает процессор процессора БД), либо я могу поместить его в свой код Java (принимает процессор серверной машины).

Есть ли какой-либо предпочтительный подход здесь (чтобы установить условия в DB Vs в середине уровня)?

UPDATE: Мой запрос является объединением более чем 2 таблицы, и я использую LEFT JOIN для объединения и Есть некоторые строки, которые будут иметь соответствующие строки в таблице 2 и некоторые из них нет. Мне нужно иметь значение по умолчанию для этих столбцов, когда у меня нет соответствующей строки во 2-й таблице.

SElECT CASE WHEN t2.col1 is null 
    then 'default' else t2.col1 
    END 
FROM table1 t1 
LEFT JOIN table2 t2 ON t1.id = t2.id 

Answer 1

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

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

Однако второе условие выше должно быть тщательно проверено: многие вещи не будут уменьшать (или даже увеличивать) нагрузку БД, если они удалены от БД.

Обновление: Для того, что вам нужно, я сомневаюсь, удовлетворено ли первое условие - вы его протестировали? Простой CASE совершенно незначителен, если условие или ветви не содержат очень дорогостоящих вычислений.

Answer 2

Да, хотя я бы предложил другой подход, который не добавляет нагрузки на сервер приложений и минимальную нагрузку на СУБД. На этот вопрос немного сложно ответить, так как вы не представили конкретный пример, но я дам ему шанс.

Мое предпочтительное решение - полностью избавиться от условий if, если вы можете. На минимальном минимуме вы можете повторно настроить схему базы данных, чтобы переместить стоимость расчета в сторону от select (что очень часто) и в insert/update (что случается реже).

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

В качестве примера предположим, что вы храните информацию о человеке, и вы хотите получить список людей, чье имя более 5 символов. Не спрашивайте, почему, я клиент, вы должны дать мне то, что я хочу :-)

Вместо чудовищного заявления select (возможно) разделить имя и подсчитать символы в нем, сделать это в качестве триггера вставки/обновления, когда данные поступают в таблицу - , то есть - единственный раз, когда значение может измениться в конце концов.

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

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

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

---

Основываясь на вашем обновлении, вы должны поставить нагрузку на машину, где она оказывает наименьшее влияние. Это может быть СУБД, это может быть сервер приложений, он может быть даже на стороне клиента (самого сервера приложений), поскольку он будет распределять затраты на множестве машин, а не концентрировать его в одной точке.

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