Сообщение Re[7]: Вертикальное масштабирование таблицы от 06.04.2017 10:01
Изменено 06.04.2017 10:06 MadHuman
Re[7]: Вертикальное масштабирование таблицы
Здравствуйте, swimmers, Вы писали:
S>Ходим по кругу.
S>Уважаемому MadHuman помог вынос блобов в отдельную таблицу.
S>Мы с вами сошлись, что нормальные СУБД и так хранят блоб отдельно.
S>Вопрос — какая у него (MadHuman)СУБД и почему все стало летать.
Вижу дисскусия набрала обороты СУБД SQLite, но дело в ней.
я не говорил что текст письма хранится в блобе, он хранится в обычном текстовом поле, иногда же письма бывают короткие.
Думаю что остальные СУБД также хранят текстовые поля в основных данных записи, ведь сама СУБД же не знает что там будет — много или мало данных.
Всё стало летать, так как при фул-скане таблицы для отработки условий выборки по другим полям, с диска перестали подниматься и прогоняться через кэш десятки Гигов данных, размер таблицы с письмами после выноса поля с текстом письма в отдельную, стал сильно меньше и даже её фул-скан стал работать быстро.
Одних лиш индексов не всегда бывает достаточно, тк вариативность условий в выборке и их комбинаций могут быть достаточно высокие, и всё индексами не покрыть, и если при имеющимся объеме данных всё это даже с фул-сканом происходит за приемлемое время — за индексы можно не заморачиваться.
S>Ходим по кругу.
S>Уважаемому MadHuman помог вынос блобов в отдельную таблицу.
S>Мы с вами сошлись, что нормальные СУБД и так хранят блоб отдельно.
S>Вопрос — какая у него (MadHuman)СУБД и почему все стало летать.
Вижу дисскусия набрала обороты СУБД SQLite, но дело в ней.
я не говорил что текст письма хранится в блобе, он хранится в обычном текстовом поле, иногда же письма бывают короткие.
Думаю что остальные СУБД также хранят текстовые поля в основных данных записи, ведь сама СУБД же не знает что там будет — много или мало данных.
Всё стало летать, так как при фул-скане таблицы для отработки условий выборки по другим полям, с диска перестали подниматься и прогоняться через кэш десятки Гигов данных, размер таблицы с письмами после выноса поля с текстом письма в отдельную, стал сильно меньше и даже её фул-скан стал работать быстро.
Одних лиш индексов не всегда бывает достаточно, тк вариативность условий в выборке и их комбинаций могут быть достаточно высокие, и всё индексами не покрыть, и если при имеющимся объеме данных всё это даже с фул-сканом происходит за приемлемое время — за индексы можно не заморачиваться.
Re[7]: Вертикальное масштабирование таблицы
Здравствуйте, swimmers, Вы писали:
S>Ходим по кругу.
S>Уважаемому MadHuman помог вынос блобов в отдельную таблицу.
S>Мы с вами сошлись, что нормальные СУБД и так хранят блоб отдельно.
S>Вопрос — какая у него (MadHuman)СУБД и почему все стало летать.
Вижу дисскусия набрала обороты СУБД SQLite, но дело в ней.
я не говорил что текст письма хранится в блобе, он хранится в обычном текстовом поле, иногда же письма бывают короткие.
Думаю что остальные СУБД также хранят текстовые поля в основных данных записи, ведь сама СУБД же не знает что там будет — много или мало данных.
Всё стало летать, так как при фул-скане таблицы для отработки условий выборки по другим полям, с диска перестали подниматься и прогоняться через кэш десятки Гигов данных, размер таблицы с письмами после выноса поля с текстом письма в отдельную, стал сильно меньше и даже её фул-скан стал работать быстро.
хочу обратить внимание, уважаемых собеседников — что речь идет об участии в условии отбора всех полей, кроме текста сообщения. понятно что messageBody like '%аааа%' положит базу и ничо не сделать (ну кроме конечно задействования полнотекстовых поисков), но речь не о них.
Одних лиш индексов не всегда бывает достаточно, тк вариативность условий в выборке и их комбинаций могут быть достаточно высокие, и всё индексами не покрыть, и если при имеющимся объеме данных всё это даже с фул-сканом происходит за приемлемое время — за индексы можно не заморачиваться.
S>Ходим по кругу.
S>Уважаемому MadHuman помог вынос блобов в отдельную таблицу.
S>Мы с вами сошлись, что нормальные СУБД и так хранят блоб отдельно.
S>Вопрос — какая у него (MadHuman)СУБД и почему все стало летать.
Вижу дисскусия набрала обороты СУБД SQLite, но дело в ней.
я не говорил что текст письма хранится в блобе, он хранится в обычном текстовом поле, иногда же письма бывают короткие.
Думаю что остальные СУБД также хранят текстовые поля в основных данных записи, ведь сама СУБД же не знает что там будет — много или мало данных.
Всё стало летать, так как при фул-скане таблицы для отработки условий выборки по другим полям, с диска перестали подниматься и прогоняться через кэш десятки Гигов данных, размер таблицы с письмами после выноса поля с текстом письма в отдельную, стал сильно меньше и даже её фул-скан стал работать быстро.
хочу обратить внимание, уважаемых собеседников — что речь идет об участии в условии отбора всех полей, кроме текста сообщения. понятно что messageBody like '%аааа%' положит базу и ничо не сделать (ну кроме конечно задействования полнотекстовых поисков), но речь не о них.
Одних лиш индексов не всегда бывает достаточно, тк вариативность условий в выборке и их комбинаций могут быть достаточно высокие, и всё индексами не покрыть, и если при имеющимся объеме данных всё это даже с фул-сканом происходит за приемлемое время — за индексы можно не заморачиваться.