Информация об изменениях

Сообщение Re[7]: Вертикальное масштабирование таблицы от 06.04.2017 10:01

Изменено 06.04.2017 10:06 MadHuman

Re[7]: Вертикальное масштабирование таблицы
Здравствуйте, swimmers, Вы писали:

S>Ходим по кругу.

S>Уважаемому MadHuman помог вынос блобов в отдельную таблицу.
S>Мы с вами сошлись, что нормальные СУБД и так хранят блоб отдельно.
S>Вопрос — какая у него (MadHuman)СУБД и почему все стало летать.

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

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

Одних лиш индексов не всегда бывает достаточно, тк вариативность условий в выборке и их комбинаций могут быть достаточно высокие, и всё индексами не покрыть, и если при имеющимся объеме данных всё это даже с фул-сканом происходит за приемлемое время — за индексы можно не заморачиваться.
Re[7]: Вертикальное масштабирование таблицы
Здравствуйте, swimmers, Вы писали:

S>Ходим по кругу.

S>Уважаемому MadHuman помог вынос блобов в отдельную таблицу.
S>Мы с вами сошлись, что нормальные СУБД и так хранят блоб отдельно.
S>Вопрос — какая у него (MadHuman)СУБД и почему все стало летать.

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

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

хочу обратить внимание, уважаемых собеседников — что речь идет об участии в условии отбора всех полей, кроме текста сообщения. понятно что messageBody like '%аааа%' положит базу и ничо не сделать (ну кроме конечно задействования полнотекстовых поисков), но речь не о них.

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