1

Тема: нужен "общий" совет при работе с Doctrine при больших БД(100кк запсей)

есть таблицы:
shedule(id,id_teacher,id_subject,id_group,...) - 100 млн записей
teacher(id,...) 100к записей
subject(id,...) 1к записей
student_group(id,...) 100к записей
(которые в свою очередь связаны с другими таблицами)

при создании объекта shedule - в форму создания подтягиваются данные из других таблиц и все "умирает".
посоветуйте - как обойти данную проблему? можно ли это делать посредством Doctrine? вручную другими методами?
или скиньте ссылки на мануалы.

2

Re: нужен "общий" совет при работе с Doctrine при больших БД(100кк запсей)

Autocomplete вместо выпадающего списка из 100к записей?

3

Re: нужен "общий" совет при работе с Doctrine при больших БД(100кк запсей)

Лимитировать выборку, объединить некоторые таблицы в 1 большую, чтобы было меньше join. 
Не использовать никаких Doctrine / queryBuilder и подобных либ. Только чистый SQL.
Опять же юзать Explain(http://habrahabr.ru/post/31129/) для определения как база использует индексы.
Если есть поиск юзать Solr / Sphinx или что-то подобное.

Ну и честно говоря 100 млн записей в shedule как-то многовато. Может можно вынести часть информации в другие таблицы, к примеру создать shedule_arhive, который будет содержать старые записи и во время запроса проверять запрошены архивные / старые данные или новые, или вообще почистить таблицу от мусора?

4

Re: нужен "общий" совет при работе с Doctrine при больших БД(100кк запсей)

esigns пишет:

Лимитировать выборку, объединить некоторые таблицы в 1 большую, чтобы было меньше join. 
Не использовать никаких Doctrine / queryBuilder и подобных либ. Только чистый SQL.

Так себе советы, прямо скажем...

Доктрине как-то глубоко похрен, сколько там записей в базе. 18 или 3 миллиарда строк. Соотношение скорости работы с Доктриной или без нее не будет отличаться на разных объемах БД.

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

Объединение таблиц — чаще навредит, так как в большинстве структур основная таблица непропорционально распухнет. Денормализацию используют, но только когда это действительно необходимо, и лучшие решения там как правило нетривиальные, разработанные под конкретную структуру данных.

По сабжу — первый ответ полностью отвечает на поставленный вопрос, так как у топикстартера проблема не в том, что в базе много записей, а в том, что он все эти записи зачем-то подгружает в списки в форме. Хотя селект с более чем сотней значений — это уже ненормально, потому что пользователь рискует убиться об стену раньше, чем найдет в выпавшей простыне то, что ему нужно.

5 Отредактировано esigns (2015-10-28 10:46:03)

Re: нужен "общий" совет при работе с Doctrine при больших БД(100кк запсей)

Привет еще раз)
Я открыл эту тему после создание своей и не посмотрев на дату отписал. Понятно что уже не актуально)
-----------

Доктрине как-то глубоко похрен, сколько там записей в базе. 18 или 3 миллиарда строк. Соотношение скорости работы с Доктриной или без нее не будет отличаться на разных объемах БД.

Это так, но Доктрина, как и в принципе любая подобная библитека, какой бы умной она не была, генерирует код для запроса  БД самостоятельно. В результате теряется контроль над содержимым запроса и может быть использован не самый оптимальный запрос(но рабочий), особенно если запрос сложный с десятком Join.
К примеру http://forum.sfhub.org/post/15092/#p15092 .

Так себе советы, прямо скажем...

Просто перечислил разные варианты, которые пришли на ум, а что больше подходит человеку - пусть сам решает, т. к. ему виднее.
Это не значит, что нужно все использовать)) Может он что-то забыл из названного, или не слышал, а я ему напомнил.

6

Re: нужен "общий" совет при работе с Doctrine при больших БД(100кк запсей)

esigns пишет:

В результате теряется контроль над содержимым запроса

Это заблуждение. default/smile
В генерации запросов за редким исключением нет никакой магии, и если разработчик достаточно хорошо изучил документацию Доктрины и хорошо понимает принцип ее работы, то в 99% случаев при описании запроса конструктором он хорошо себе представляет конечный SQL-запрос, который сгенерирует Доктрина. Плюс, отладку никто не отменял. Можно сконструировать запрос, получить его конечный сгенерированный SQL, изучить и прогнать его на профайлере и в результате скорректировать построение в конструкторе так, чтобы он генерировал оптимальный запрос. Запросы, которые нельзя оптимально (или вовсе) описать в конструкторе — редкость.