powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Большая таблица, мало RAM
87 сообщений из 87, показаны все 4 страниц
Большая таблица, мало RAM
    #37622133
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Какие существуют бесплатные решения позволяющие работать с большими таблицами (1 млрд.) на железе с ограниченной RAM. Т.е. когда даже индексы целиком не помещаются в память и невозможно расшардить таблицу на несколько машин.
Что можно придумать кроме партицирования чтобы получить хотя бы примерно линейную зависимость производительности от количества строк? При том что даже в случае партицирования могут быть запросы читающие со всех партиций. Спасибо.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622146
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehilЧто можно придумать кроме партицирования чтобы получить хотя бы примерно линейную зависимость производительности от количества строк? При том что даже в случае партицирования могут быть запросы читающие со всех партиций. Спасибо.А она и так будет линейной в худшем случае. И с очень большим множителем (из-за физического ввода-вывода).
Обычно стремятся сделать быстрее, чем линейную. В чем помогают, например, индексы.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622152
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehil,

Вы огласите задачу более детально. Пока же ничего определенного сказать нельзя. Может, любая СУБД будет одинаково плоха. А может, обычные файлы спасут.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622156
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
И да, аналитики совсем не нужно, больше на OLTP похоже.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622164
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Производительность не будет линейной хотя бы из за того что при небольшом количестве записей индексы влазят в память, при большом - уже ничего не влазит. Доступ к строкам примерно равномерный, нету распределения по времени. Большинство запросов по ПК, часть - по другим индексированным полям.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622185
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehilПроизводительность не будет линейной хотя бы из за того что при небольшом количестве записей индексы влазят в память, при большом - уже ничего не влазит.Да, по достижении некоторого порога будет скачок, но за ним картина опять будет той же (с индексом - логарифмическйи рост, без индекса - линейный).
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622193
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoftthehilПроизводительность не будет линейной хотя бы из за того что при небольшом количестве записей индексы влазят в память, при большом - уже ничего не влазит.Да, по достижении некоторого порога будет скачок, но за ним картина опять будет той же (с индексом - логарифмическйи рост, без индекса - линейный).

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

Нужны ещё варианты. Причем бесплатные.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622204
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А партиционирование где бесплатное?
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622226
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehilЭто и понятно, цель - преодолеть скачок.Никак не преодолете. Либо физический ввод/вывод не нужен (нужные данные есть в ОП), либо нужен. Во втором случае совсем другие времена.

Максимум, что в этой ситуации поможет, имхо:
1) правильный алгоритм кэширования, чтобы для наиболее критичных по времени запросов была выше вероятность обойтись данными в ОП.
2) правильное использование индексов и других механизмов СУБД, позволяющие минимизировать физический ввод/вывод. И не вовсе не факт, что партиционирование тут поможет.

Пока не описана четко задача - можно теоретизировать бесконечно. Оптимизировать можно только частный случай.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622261
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В случае Oracle, партишионирование поддерживает только EE - это сотни тысяч долларов на один сервер. С DB2 аналогично.

Postgres?
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622292
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Victor Metelitsa,

Да PostgreSQL поддерживает, да и на крайний случай MySQL тоже может.

Насчет подробнестей - уточните что вы ещё хотите услышать?
Есть отностительно слабый сервер, из железа больше ничего. Есть таблица с миллионами строк, хочется чтобы разростание до миллиардов не привело к заметному ухудшению времени отклика. Апп сервер на той же машине. Запросов не много, до нескольких в секунду. Запросы элементарные: дай/удали/измени строку по id в основном (80%), немного запросов по другим полям из этой же таблицы, использующие индекс (10%), есть несколько джойнов с такой же большой таблицей по id. Везде индексы и на небольших объёмах данных отклик устраивает.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622296
thehil , А про нелинейную зависимость в OLTP от размера таблицы это вы тестами определили или предположили?
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622297
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Была мысль насчет шардинга mongodb на одной машине, но походу это гиблое дело.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622305
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
нелинейную зависимость в OLTP,

Предположин, да и люди выше подтвердили. Пока всё в памяти - логарифмически, как только не влазит - должно хуже. Сейчас попробую провести тест в условиях ограниченной памяти.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622307
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehilЗапросов не много, до нескольких в секунду.Ну тут и с дисковыми чтениями ничего страшного не будет.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622315
thehilVictor Metelitsa,

Да PostgreSQL поддерживает, да и на крайний случай MySQL тоже может.

Насчет подробнестей - уточните что вы ещё хотите услышать?
Есть отностительно слабый сервер, из железа больше ничего. Есть таблица с миллионами строк, хочется чтобы разростание до миллиардов не привело к заметному ухудшению времени отклика. Апп сервер на той же машине. Запросов не много, до нескольких в секунду. Запросы элементарные: дай/удали/измени строку по id в основном (80%), немного запросов по другим полям из этой же таблицы, использующие индекс (10%), есть несколько джойнов с такой же большой таблицей по id. Везде индексы и на небольших объёмах данных отклик устраивает.
Сколько ОЗУ? Какая СУБД?
Первые 2-3 уровня индекса будут закэшированы. Партиционирование это фактически ещё один уровень индекса. Здесь удобство бывает в том, что с партициями можно работать как с обычными таблицами и переносить их между тейблспейсами и соотвественно на другие СХД.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622322
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoft,

Возможно. Но в любом случае чтение с диска заметно медленнее чем из памяти. В случае с партицирование есть шанс выделить наиболее используемые данные в одну партицию и тогда шанс попадание в кеш индекса для этой партиции должен быть выше.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622327
thehilнелинейную зависимость в OLTP,

Предположин, да и люди выше подтвердили. Пока всё в памяти - логарифмически, как только не влазит - должно хуже. Сейчас попробую провести тест в условиях ограниченной памяти.
Если подтвердиться то только шардинг, кластер или добавлять памяти.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622329
thehilmiksoft,

Возможно. Но в любом случае чтение с диска заметно медленнее чем из памяти. В случае с партицирование есть шанс выделить наиболее используемые данные в одну партицию и тогда шанс попадание в кеш индекса для этой партиции должен быть выше.
Попробуйте "провести тест в условиях ограниченной памяти." и если будут ухудшения, то попробуйте от них избавиться "выделить наиболее используемые данные в одну партицию и тогда шанс попадание в кеш индекса для этой партиции должен быть выше.".
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622331
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сколько ОЗУ? Какая СУБД?Сколько ОЗУ? Какая СУБД?
Первые 2-3 уровня индекса будут закэшированы. Партиционирование это фактически ещё один уровень индекса. Здесь удобство бывает в том, что с партициями можно работать как с обычными таблицами и переносить их между тейблспейсами и соотвественно на другие СХД.
Сейчас PostgreSQL, но возможно поменять на абсолютно любую бесплатную. ОЗУ может меняться, т.к. приложение целиком с базой ставится на клиентский сервер. Давайте предположим что минимум 4 Gb ОЗУ.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622335
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
нелинейную зависимость в OLTPthehilнелинейную зависимость в OLTP,

Предположин, да и люди выше подтвердили. Пока всё в памяти - логарифмически, как только не влазит - должно хуже. Сейчас попробую провести тест в условиях ограниченной памяти.
Если подтвердиться то только шардинг, кластер или добавлять памяти.
К сожалению все эти варианты сразу отпадают.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622336
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehilmiksoft,

Возможно. Но в любом случае чтение с диска заметно медленнее чем из памяти.Пока не озвучены четкие цифры вида "такой-то SQL-запрос на таких-то данных отрабывает за X секунд, а допустимо не более чем за Y секунд в Z% случаев" ваши фразы типа "заметно медленнее" - ни о чем.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622345
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Victor MetelitsaВ случае Oracle, партишионирование поддерживает только EE - это сотни тысяч долларов на один сервер. С DB2 аналогично.

Partition Views есть в любой оракловой редакции
http://docs.oracle.com/cd/A57673_01/DOC/server/doc/A48506/partview.htm#351

в постгрес взрослого партитионинга нет, но есть те же самые Partition Views
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622354
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehilЕсть отностительно слабый сервер, из железа больше ничего. Есть таблица с миллионами строк, хочется чтобы разростание до миллиардов не привело к заметному ухудшению времени отклика. Апп сервер на той же машине. Запросов не много, до нескольких в секунду. Запросы элементарные: дай/удали/измени строку по id в основном (80%), немного запросов по другим полям из этой же таблицы, использующие индекс (10%), есть несколько джойнов с такой же большой таблицей по id. Везде индексы и на небольших объёмах данных отклик устраивает.

Загрузите тестовыми данными, да посмотрите. Лично мне кажется, что при такой абстрактной постановке и с миллиардами записей будет терпимо работать (причём даже без партишионирования, но при наличии подходящих индексов). Вот бекапы делать - это да...
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622380
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!Victor MetelitsaВ случае Oracle, партишионирование поддерживает только EE - это сотни тысяч долларов на один сервер. С DB2 аналогично.

Partition Views есть в любой оракловой редакции
http://docs.oracle.com/cd/A57673_01/DOC/server/doc/A48506/partview.htm#351

А... Я уже забыл про эту фичу (в DB2 такое можно также на любых версиях)
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622523
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Victor MetelitsaЗагрузите тестовыми данными, да посмотрите. Лично мне кажется, что при такой абстрактной постановке и с миллиардами записей будет терпимо работать (причём даже без партишионирования, но при наличии подходящих индексов). Вот бекапы делать - это да...
Смотрите, провёл простой тест:
1) одна таблица 100 строк, 512М памяти, индексы влазят в память, запрос по id - 5ms
2) одна таблица 1М строк, 512М памяти, индексы влазят в память, запрос по id - 5ms
3) одна таблица 20М строк, 512М памяти, индексы НЕ влазят в память, запрос по id - 150-50ms
Ухудшение в 10 раз.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622587
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehilVictor MetelitsaЗагрузите тестовыми данными, да посмотрите. Лично мне кажется, что при такой абстрактной постановке и с миллиардами записей будет терпимо работать (причём даже без партишионирования, но при наличии подходящих индексов). Вот бекапы делать - это да...
Смотрите, провёл простой тест:
1) одна таблица 100 строк, 512М памяти, индексы влазят в память, запрос по id - 5ms
2) одна таблица 1М строк, 512М памяти, индексы влазят в память, запрос по id - 5ms
3) одна таблица 20М строк, 512М памяти, индексы НЕ влазят в память, запрос по id - 150-50ms
Ухудшение в 10 раз.
А теперь напрашивается проверить 200M.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622607
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Victor Metelitsa,

эх... место на VM кончилось, нужно время чтобы пересоздать с большим HDD. Ждите, продолжение следует :)
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622632
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehil3) одна таблица 20М строк, 512М памяти, индексы НЕ влазят в память

Это что за индексы, что они для 20М строк в память не влазят?.. Неужели PostrgreSQL их
совсем никак не сжимает?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622641
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov,

обычный индекс по bigserial на 20М строк занял что-то около 600 Мб
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622653
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
РСУБД изначально делали в предположении, что все данные в память не влазят. Это сейчас ОЗУ - как грязи. (Посмотрите, кстати, какие сейчас цены на память. Для самосбора можно брать по 8 гиг ECC за 2.5тр - я недавно даже вообразить такое не мог).

Чтение одной страницы - ну, где-то 10-15ms на позиционирование головки и 0.1ms собственно на считывание 8-килобайтного блока, это для дешёвых SATA-шных винчестеров. Поиск в индексе - это просто проход через его уровни, то есть считывание нескольких страниц. С ростом величины таблицы количество уровней увеличивается ОЧЕНЬ слабо - я как-то не уверен, повысится ли количество уровней хотя бы на 1 при повышении количества записей в таблице со 20M до 200M.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622662
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Victor Metelitsa,

Т.е. вы предлагаете не заморачиваться и хранить таблицу с милиардами строк, с сотнями гигабайт данных как есть?
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622707
thehilVictor MetelitsaЗагрузите тестовыми данными, да посмотрите. Лично мне кажется, что при такой абстрактной постановке и с миллиардами записей будет терпимо работать (причём даже без партишионирования, но при наличии подходящих индексов). Вот бекапы делать - это да...
Смотрите, провёл простой тест:
1) одна таблица 100 строк, 512М памяти, индексы влазят в память, запрос по id - 5ms
2) одна таблица 1М строк, 512М памяти, индексы влазят в память, запрос по id - 5ms
3) одна таблица 20М строк, 512М памяти, индексы НЕ влазят в память, запрос по id - 150-50ms
Ухудшение в 10 раз.
А теперь попробуйте тот же самый тест с партиционированием. Результаты эквивалентны будут. 150 ms.
Только тот же самый, а не другой.

А вот если sharding сделать, то останется в пределах 5ms.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622733
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehilVictor Metelitsa,

Т.е. вы предлагаете не заморачиваться и хранить таблицу с милиардами строк, с сотнями гигабайт данных как есть?
Производительность, как мне кажется, будет удовлетворительной (на тех запросах и в тех рамках,что вы описали), но советую удостовериться лично. И, кроме производительности тех запросов, надо рассматривать другие проблемы (вроде неудобства делания бекапов или пресловутого "вакуума") - имеет смысл провести натурные испытания.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622734
Victor MetelitsaРСУБД изначально делали в предположении, что все данные в память не влазят. Это сейчас ОЗУ - как грязи. (Посмотрите, кстати, какие сейчас цены на память. Для самосбора можно брать по 8 гиг ECC за 2.5тр - я недавно даже вообразить такое не мог).

Чтение одной страницы - ну, где-то 10-15ms на позиционирование головки и 0.1ms собственно на считывание 8-килобайтного блока, это для дешёвых SATA-шных винчестеров. Поиск в индексе - это просто проход через его уровни, то есть считывание нескольких страниц. С ростом величины таблицы количество уровней увеличивается ОЧЕНЬ слабо - я как-то не уверен, повысится ли количество уровней хотя бы на 1 при повышении количества записей в таблице со 20M до 200M.
Да, на сервер не сложно поставить 64ГБ.
Но если у него сотни ГБ данных, то это не спасет. Пусть даже индекс влезет, но данные - нет. А это обращение к диску и ухудшение скорости на 2-3 порядка.
Так же не спасет и партиционирование.

Если идет обращение только к 10% записи, то и сервер закжширует только эти 10%, и только на них необходимо будет ОЗУ. С партиционированием или без - это без разницы.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622764
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
это без разницы]А это обращение к диску и ухудшение скорости на 2-3 порядка.
SSD диски - сильная вещь.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622776
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakovэто без разницыА это обращение к диску и ухудшение скорости на 2-3 порядка.SSD диски - сильная вещь.Кстати, да!
Мы недавно пробовали Oracle XE на SSD со схожей проблемой - объем данных не влезал в отведенный гиг. Самый тяжелый запрос в приложении вместо 10-30 секунд на обычном SATA-диске (колебалось в зависимости от параметров) стал выполняться за 2-3 секунды на SSD (причем весьма бюджетном, Vortex3 60Гб).
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37622788
Dimitry Sibiryakovэто без разницы]А это обращение к диску и ухудшение скорости на 2-3 порядка.
SSD диски - сильная вещь.

Все относительно:
Скорость RAM - 20 000 МБ/сек
Скорость SSD - 300 МБ/сек (SATAII)
Скорость HDD - 100 МБ/сек (Sequetial)
Скорость HDD - 10 МБ/сек (Random)
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37623192
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sharding сделатьDimitry Sibiryakovпропущено...

SSD диски - сильная вещь.

Все относительно:
Скорость RAM - 20 000 МБ/сек
Скорость SSD - 300 МБ/сек (SATAII)
Скорость HDD - 100 МБ/сек (Sequetial)
Скорость HDD - 10 МБ/сек (Random)
HDD random, по-моему, много хуже. Вообще, эти цифры не дают правильного ощущения разрыва в скорости между HDD и SSD.

У "дешёвого" SATA HDD основное время уйдёт 10-15ms на позиционирование головки. Дальнейшее считывание, примерно 0.1ms на 8K данных, из расчёта средней скорости считывания 80 мег в секунду, совершенно незаметно на этом фоне.

SSD нет нужды позиционировать головки, за неимением таковых. Поэтому на чтение реальная разница на произвольном доступе фантастическая.

Но ведь они и дорогие очень, особенно "ентерпрайзные", надёжность... подозрительная, да и с записью совсем не так хорошо.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37627814
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Если кому-нибудь интересно: провёл тестирование pgbench-ем (PostgreSQL), продакшн схемы, продакшн запросом (выборка записи по ID). Результат — как только база достигает размеров памяти производительность резко падает где-то в 50 раз. До скачка — 4000 запросов в секунду, после — 30 до 120 запросов в секунду. Все настройки по-умолчанию (только не надо объяснять что это плохо).
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37627850
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehil, ты уже определился, над чем бьёшся: чтобы "скачка после роста БД не было" (ищем чудо-пулю) или чтобы "если в память не влазим, быстродействие должно упасть не ниже конкретного Ч"?

По определению, если в память не влазим - будет медленнее, потому что если с винта можно брать чудо-алгоритмом, то из памяти можно сделать то же самое - но гораздо быстрее :) :(.
Повышение быстродействия ПО с использованием конкретной БД обычно и сводится к тому, чтобы для большинства запросов нужная информация бралась из кеша в ОЗУ, а не с диска..
Вариант: ускорить винт, но SSD (твердотельные накопители) уже предлагали...
Если при прочих равных (на том же железе), то остаётся только средствами администрирования оптимизировать работу СУБД, ПО или улучшить схему хранения данных...

Неужели действительно нет критериев, чтобы выделить наиболее востребованную часть БД, а для отсальных запросов сказать, что вы будете выполняться таки за 100мс?
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37627911
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehilпосле — 30 до 120 запросов в секунду
Не верю. Если в кэш не помещается последний уровень индекса, то чтение каждой запись
вызывает чтение одной страницы индекса и одной - данных. Пусть даже действительность хуже
и на каждую запись надо прочитать 4 страницы. Пусть каждая страница 16 килобайт. Умножаем
на 120 запросов в секунду получаем нагрузку на ввод-вывод чуть меньше восьми мегабайт в
секунду. У вас база что, на дискете была?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37627923
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakovthehilпосле — 30 до 120 запросов в секунду
получаем нагрузку на ввод-вывод чуть меньше восьми мегабайт в
секунду



sharding сделатьСкорость HDD - 10 МБ/сек (Random)

вроде сходится :)
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37627931
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakovthehilпосле — 30 до 120 запросов в секунду
Не верю. Если в кэш не помещается последний уровень индекса, то чтение каждой запись
вызывает чтение одной страницы индекса и одной - данных. Пусть даже действительность хуже
и на каждую запись надо прочитать 4 страницы. Пусть каждая страница 16 килобайт. Умножаем
на 120 запросов в секунду получаем нагрузку на ввод-вывод чуть меньше восьми мегабайт в
секунду. У вас база что, на дискете была?..
Это же короткие одноблочные чтения, почти для каждого приходится ждать нужного сектора и/или двигать головки диска, так что все нормально.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37627941
ДохтаР
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А какая у вас ОСь ?

Если что то unix -подобное покажите

vmstat 1 20
для этого случая
thehil после — 30 до 120 запросов в секунду. Все настройки по-умолчанию (только не надо объяснять что это плохо).
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37627947
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛойвроде сходится :)
Тогда возникает вопрос: зачем PG на каждую запись читает пять страниц?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37627955
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovАнатоЛойвроде сходится :)
Тогда возникает вопрос: зачем PG на каждую запись читает пять страниц?

Дык мы ж ничего не знаем ни про железо, ни про версию Pg, ни про настройки Pg, ни про схему БД, ни про физическое расположение файлов БД, ни про запрос, которым ТС в БД долбится, ни про статистику, ни про план выполнения запроса...
А среднепотолочно - похоже :)...
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37627961
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛоймы ж ничего не знаем
Из железа мы знаем 500Мб ОЗУ. Из настроек - всё по дефолту. Из запроса - запись выбирается
по первичному ключу. А в остальном - да, партизанит ТС не на шутку.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37627967
Dimitry Sibiryakovthehilпосле — 30 до 120 запросов в секунду
Не верю. Если в кэш не помещается последний уровень индекса, то чтение каждой запись
вызывает чтение одной страницы индекса и одной - данных. Пусть даже действительность хуже
и на каждую запись надо прочитать 4 страницы. Пусть каждая страница 16 килобайт. Умножаем
на 120 запросов в секунду получаем нагрузку на ввод-вывод чуть меньше восьми мегабайт в
секунду. У вас база что, на дискете была?..

Плохо считаете. Считайте не в мегабайтах, а в IOPs.
По вашему сколько один HDD выдает IOPS'ов?
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37627986
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry SibiryakovАнатоЛоймы ж ничего не знаем
Из железа мы знаем 500Мб ОЗУ. Из настроек - всё по дефолту. Из запроса - запись выбирается
по первичному ключу. А в остальном - да, партизанит ТС не на шутку.

Ну что ещё добавить: PG 9.1, тесты производились с фильтром по случайному ID.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37627993
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
thehilНу что ещё добавить: PG 9.1, тесты производились с фильтром по случайному ID.
Система unix (тестировалось на ubuntu 11.10).
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37628005
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehilНу что ещё добавить

Да как обычно: DDL, план, статистику использованного индекса и как уже сказали - результат
iostat.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37628031
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehilЕсли кому-нибудь интересно: провёл тестирование pgbench-ем (PostgreSQL), продакшн схемы, продакшн запросом (выборка записи по ID). Результат — как только база достигает размеров памяти производительность резко падает где-то в 50 раз. До скачка — 4000 запросов в секунду, после — 30 до 120 запросов в секунду. Все настройки по-умолчанию (только не надо объяснять что это плохо).
А как дела с миллиардом записей?
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37628089
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Metelitsaпосле — 30 до 120 запросов в секунду. Все настройки по-умолчанию (только не надо объяснять что это плохо).
А как дела с миллиардом записей?[/quot]
ТС, это Victor Metelitsa или ваше упорство проверяет, или намекает, что по сравнению с последним проверенным вариантом производительность будет падать не катастрофично.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37628092
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пардон, квотирование слетело
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37628105
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovАнатоЛоймы ж ничего не знаем
Из железа мы знаем 500Мб ОЗУ.
Ничего не изменилось бы в постановке вопроса, будь там 2 GB или 16 GB.
Из настроек - всё по дефолту.
Версия сервера была неизвестна - так что это тоже вилами по воде.
Из запроса - запись выбирается по первичному ключу.
Какого размера запись - нам всё равно, правда
А в остальном - да, партизанит ТС не на шутку.
Так отож. Решил, что за бесплатно должно существовать решение проблемы, а все остальные просто так мучаются. Или что ну не может жизнь быть такой сложной :)
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37628150
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛойТС, это Victor Metelitsa или ваше упорство проверяет, или намекает, что по сравнению с последним проверенным вариантом производительность будет падать не катастрофично.

На самом деле, вопрос не настолько очевиден, как мне казалось поначалу. Потому что среднее время на позиционирование головок может заметно возрасти с увеличением объёма данных (головкам приходится перемещаться на большее расстояние), так что, хотя само количество чтений на поиск одной записи может возрасти незначительно, зато количество чтений в секунду может заметно упасть.

Вот одна из причин, почему я считаю очень важным проверять предположения на практике. Натурные испытания могут помочь выявить важные тонкости. Но сейчас у меня нет "свободного" "железа" под такой тест.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37629718
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
АнатоЛойDimitry Sibiryakovпропущено...

Из железа мы знаем 500Мб ОЗУ.
Ничего не изменилось бы в постановке вопроса, будь там 2 GB или 16 GB.
Из настроек - всё по дефолту.
Версия сервера была неизвестна - так что это тоже вилами по воде.
Из запроса - запись выбирается по первичному ключу.
Какого размера запись - нам всё равно, правда
А в остальном - да, партизанит ТС не на шутку.
Так отож. Решил, что за бесплатно должно существовать решение проблемы, а все остальные просто так мучаются. Или что ну не может жизнь быть такой сложной :)


Я решил что возможно кто-то уже сталкивался в жизни с подобным и сможет помочь советом или сказать что решения нету.
Могу добавить вот что: железо неизвестно и более того оно может варьироваться в хоед работы (виртуальный сервак в амазоне может уменьшать размер памяти и цпу по достижении лимитов). В чём я вижу возможный плюс партицирования: теоретически какая-то часть данных будет использоваться чаще (хоть на десяток процентов но всё же), если выделить эту часть в отдельную партицию - больше шансов что нужный индекс и данные не будут выталкиваться из памяти. Я опять не прав?

Может существуют какие-то другие СУБД которые позволяют быстро искать в большом массиве данных не опираясь на память? Понимаю, что это из области фантастики (тут либо читать из памяти, либо с диска) но всё же. Может есть продукт который нацелен именно на это (особая организация данных на диске или индексов или всерх интеллектуальное кеширование)?

Пока план - провести тесты с учётом партицирования и настройками сервера, дальше - пытаться оптимизировать даннные, чтобы максимально уменьшить размер строки и таблиц вцелом. Ещё предложения?
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37629749
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehilЕщё предложения?
Пойти в раздел PG чтобы тебе помогли понять почему он тормозит. Немного зная работу
Firebird изнутри, я могу сказать, что для неё подобная производительность на
вышеприведённых примерах была бы подозрительно низкой. Как я уже сказал: чтобы так
тормозить, нужно читать по пять страниц на запись. Это лишко. Как минимум два первых
уровня индекса должны были влезть в кэш по-любому.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37629770
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehilЯ решил что возможно кто-то уже сталкивался в жизни с подобным и сможет помочь советом или сказать что решения нету.

В такой обобщённой формулировке, наверное
* сталкивались все с хотя бы с каким-то минимальным опытом
* для такого абстрактного вопроса подобного же абстрактного решения, естественно, нету
Могу добавить вот что: железо неизвестно и более того оно может варьироваться в хоед работы (виртуальный сервак в амазоне может уменьшать размер памяти и цпу по достижении лимитов). В чём я вижу возможный плюс партицирования: теоретически какая-то часть данных будет использоваться чаще (хоть на десяток процентов но всё же), если выделить эту часть в отдельную партицию - больше шансов что нужный индекс и данные не будут выталкиваться из памяти. Я опять не прав?

Это зависит от данных, разумеется. Что за данные-то, и что за запросы? Свои данные я представляю: если у меня авиабилетов на более пяти лет, но основная работа идёт с последней пару месяцев, то они и так сбиты в кучку, естественным образом (по мере ввода), и партишены не особо важны. Подобная ситуация возникнет у вас, если вы в основном ищете по id более-менее последневставленные записи.
Может существуют какие-то другие СУБД которые позволяют быстро искать в большом массиве данных не опираясь на память? Понимаю, что это из области фантастики (тут либо читать из памяти, либо с диска) но всё же. Может есть продукт который нацелен именно на это (особая организация данных на диске или индексов или всерх интеллектуальное кеширование)?

Почему тогда просто не воспользоваться генератором случайных чисел? А ещё проще константу задать.

Юзер: @#@$ &@&7 @%@%?
Программа: НЕТ.

Быстро, надёжно, к диску не обращается, много ОЗУ не требует, потребляет мало процессорных ресурсов.

ха,

У Oracle есть IOT (index organized tables), это может чуть сэкономить в поиске в некоторых случаях.
У Oracle и DB2 есть компрессия данных и индексов, но это ОЧЕНЬ дорого.

У DB2 есть действительно ОЧЕНЬ быстрый поиск без всяких индексов, когда таблица по внутреннему устройству изображает из себя статический массив классических языков программирования.

http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.sql.ref.doc/doc/r0000927.html?resultof=%22%63%72%65%61%74%65%22%20%22%63%72%65%61%74%22%20%22%74%61%62%6c%65%22%20%22%74%61%62%6c%22%20

Код: sql
1.
2.
3.
4.
5.
6.
CREATE TABLE xxx(
  i INTEGER NOT NULL,
  v VARCHAR(100)
)
ORGANIZE BY KEY SEQUENCE (i STARTING FROM 1 ENDING AT 1000000000)
ALLOW OVERFLOW



Создаётся таблица xxx на 1000000000 строк. Размер строки фиксированный (стало быть, под поле v всегда выделено 100 байтов плюс оверхед, хоть это и varchar), место на диске под все 1000000000 выделяется сразу. Для запросов вида
Код: sql
1.
  SELECT ... FROM xxx WHERE i=?


индексы не нужны, потому что по ключу легко вычисляется смещение.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37629774
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Но если желаете остаться в пределах этого раздела - пожалуйста. Индексы в PG включают в
себя не только данные, но и отметки версий. Это делает его индексы больше и менее
эффективными. Поэтому они не влазят в ваше ОЗУ. Выкиньте эту гадость.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37629780
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovНо если желаете остаться в пределах этого раздела - пожалуйста. Индексы в PG включают в
себя не только данные, но и отметки версий. Это делает его индексы больше и менее
эффективными. Поэтому они не влазят в ваше ОЗУ. Выкиньте эту гадость.

Говорят, что FB/IB неспособен на Index only access именно потому, что у индексов нет отметок версий и он вынужден лезть в таблицу тогда, когда DB2 и Oracle легко без этого обходятся. Если PG умеет тоже, ему это в плюс.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37629781
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehil Я решил что возможно кто-то уже сталкивался в жизни с подобным и сможет помочь советом или сказать что решения нету.Вы пытаетесь найти черную кошку в темной комнате т.е. найти идеальное решение вообще .
thehil В чём я вижу возможный плюс партицирования: теоретически какая-то часть данных будет использоваться чащеОтвет неверный. Плюс партиционирования в том, чтобы в результате административных действий (заливка, переиндексация, обновление ...) простой был бы только для тех, кто трогает эту партицию, а не для всех.
thehil какая-то часть данных будет использоваться чаще Доступ идет поблочно. Чаще используемые блоки по-любому будут в ОЗУ.
thehil Может существуют какие-то другие СУБД которые позволяют быстро искать в большом массиве данных не опираясь на память? Найдя волшебную СУБД ХХХ умеющую сверхбыстро делать ваш поиск, вы можете СУЩЕСТВЕННО проиграть в других областях. Бесплтатных ланчей не бывает.

thehil Пока план - провести тесты с учётом партицирования и настройками сервера, дальше - пытаться оптимизировать даннные, чтобы максимально уменьшить размер строки и таблиц вцелом. Ещё предложения?Танцевать от печки как предлагали в первых постах топика. То есть - кто ваши пользователи, как часто будут запросы, сколько во времени отклика занимает именно поиск блока (а не соединение, аутентификация, парсинг запроса и т.д.).?
Есть ли возможность разделить пользователей во времени/пространстве (каждому пользователю свой сервер
Как происходит обновление инфы?
Если требования ко времени отклика очень жесткие, то почему заказчик не может тупо добавить железа (это гораздо проще понятнее надежнее)

Хрустальный шар мне подсказывает что вы оптимизируете коробочное решение для наислабейшего железа, максимально возможного размера базы, при пике пользовательской активности и минимальных усилиях администратора.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37629783
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaГоворят, что FB/IB неспособен на Index only access именно потому, что у индексов нет
отметок версий и он вынужден лезть в таблицу тогда, когда DB2 и Oracle легко без этого
обходятся. Если PG умеет тоже, ему это в плюс.

В данном случае - в минус, поскольку ему приходится лезть на диск не только за данными но
и индексом.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37629786
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovVictor MetelitsaГоворят, что FB/IB неспособен на Index only access именно потому, что у индексов нет
отметок версий и он вынужден лезть в таблицу тогда, когда DB2 и Oracle легко без этого
обходятся. Если PG умеет тоже, ему это в плюс.

В данном случае - в минус, поскольку ему приходится лезть на диск не только за данными но
и индексом.

Мы ведь не знаем, за какими данными он лезет, а также других вещей кучу.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37629793
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaМы ведь не знаем, за какими данными он лезет
Нет, я, конечно, тоже о ТСе не лучшего мнения, но подозревать, что он делает выборки типа
Код: sql
1.
select ID from T where ID=123



Это означает напрямую назвать его идиотом.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37629804
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov,

Ладно, раз разговор перетекает в такое русло, то на этом закончим. Всем спасибо! Буду оптимизировать своего сферического коня в вакууме сам.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37629810
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257thehil В чём я вижу возможный плюс партицирования: теоретически какая-то часть данных будет использоваться чаще

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

Эээ... Это касается исключительно Pg?
Потому что в Informix, к примеру, партиционирование и партиции (там оно исторически называется fragmentation и fragments) учитывается оптимизатором и может использоваться для повышения производительности запросов. Например, 1) размазывая строки одной таблицы по разным дискам, позволяет расширить узкое горлышко дискового ввода-вывода... 2) статистика для партиций ведётся отдельно, что повышает её точность... 3) индексы тоже могут быть партиционированы и могут храниться с размером страницы, отличным от размера страницы таблицы etc...
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37629868
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛой Потому что в Informix, к примеру, партиционирование и партиции (там оно исторически называется fragmentation и fragments) учитывается оптимизатором и может использоваться для повышения производительности запросов.Все так, СУБД знает от этом факте (партиции) и выжимает из этого все, что можно. Однако я утверждаю, что это сопутствующий бонус к улучшенной управляемости для больших баз.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37629882
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehil Буду оптимизировать своего сферического коня в вакууме сам. Флаг в руки, барабан на шею.
Просто возможна ситуация, когда вы разработаете сложный, хитрый алгоритм (найдете экзотическую СУБД) показывающий чудеса производительности на ваших тестах, а реальный заказчик добавит памяти, поставит крутую СХД, разведет пользователей по нодам, нивелируя ваш алгоритм, но будет плеваться работая с вашими вывертами.
http://ru.wikipedia.org/wiki/KISS_(принцип)
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37629978
thehil
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
SERG1257Флаг в руки, барабан на шею.
Откуда столько агресивности? Если готовы сказать по делу — говорите, пустозвонства не надо.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37629983
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
thehil Откуда столько агресивности? Желаю удачи.

Так лучше? А по сути то же самое.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37630822
Victor MetelitsaУ Oracle и DB2 есть компрессия данных и индексов, но это ОЧЕНЬ дорого.
В каком смысле дорого?
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37630833
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaУ Oracle и DB2 есть компрессия данных и индексов, но это ОЧЕНЬ дорого.
У IBM Informix тоже есть.

В каком смысле дорого?В каком смысле дорого?
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37630842
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В каком смысле дорого?В каком смысле дорого?

Наверное в том, что раз ТС не может память расширять под свои проблемы, то лицензии коммерческого ПО с такими фичами и под такие объёмы закупать - будет дорого...
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37630886
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛойлицензии коммерческого ПО с такими фичами и под такие объёмы закупать - будет дорого...

Это "коммерческое ПО" туда просто не установится из-за аппаратных требований. Тот же
Firebird использует сжатие как данных так и индексов, но аффтар уже привязался к слону...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37630889
Dimitry SibiryakovАнатоЛойлицензии коммерческого ПО с такими фичами и под такие объёмы закупать - будет дорого...

Это "коммерческое ПО" туда просто не установится из-за аппаратных требований. Тот же
Firebird использует сжатие как данных так и индексов, но аффтар уже привязался к слону...

Ну у Firebird сжатие это сильно сказано :)
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37631291
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
сильно сказаноНу у Firebird сжатие это сильно сказано :)А что же это? Это не сжатие, или существует другой, специальный термин?
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37631377
WildSeryсильно сказаноНу у Firebird сжатие это сильно сказано :)А что же это? Это не сжатие, или существует другой, специальный термин?
Поле varchar2(100) - это тоже сжатие, занимает обычно меньше 100.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37631453
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
сильно сказаноНу у Firebird сжатие это сильно сказано :)ФБ на самом деле жмёт строки при записи на диск.
Вот простая иллюстрация:
1) скрипт для заполнения базы плохо сжимаемыми данными:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
--file = 'filbin.sql'
recreate table t(id int, s01 char(64) character set octets);
commit;
set term ^;
execute block as 
declare n int = 100000;
begin
  while (n>0) do insert into t values(:n-1, gen_uuid()||gen_uuid()||gen_uuid()||gen_uuid() ) returning :n-1 into n;
end^
set term ;^
commit;


2) скрипт для заполнения базы строками вида "аааа...ааа":
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
-- file = 'filtext.sql'
recreate table t(id int, s01 char(64));
commit;
set term ^;
execute block as 
declare n int = 100000;
begin
  while (n>0) do insert into t values(:n-1, lpad('',64,'a') ) returning :n-1 into n;
end^
set term ;^
commit;


Создаем и заполняем по этим скриптам две базы :
Код: plaintext
1.
2.
3.
4.
SQL> create database 'tmpuncompressed.fdb' pagesize 8192; commit;
SQL> in filbin.sql;
SQL> create database 'tmpcompressed.fdb' pagesize 8192; commit;
SQL> in filtext.sql;
SQL> quit;

Смотрим размеры файлов:
Код: plaintext
1.
2.
C:\1INSTALL\FIREBIRD\FB25>dir tmp*.fdb
25.01.2012  18:13             6 922 240  TMPCOMPRESSED.FDB
25.01.2012  18:13            14 262 272  TMPUNCOMPRESSED.FDB

Статистика по заполнению страниц для этих баз:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
C:\1INSTALL\FIREBIRD\FB25>gstat -r TMPCOMPRESSED.FDB
<... skipped ...>
Analyzing database pages ...
T (128)
    Primary pointer page: 148, Index root page: 149
     Average record length: 10.99 , total records: 100000
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 614, data page slots: 614, average fill: 56%
    Fill distribution:
	 0 - 19% = 0
	20 - 39% = 1
	40 - 59% = 613
	60 - 79% = 0
	80 - 99% = 0

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
C:\1INSTALL\FIREBIRD\FB25>gstat -r TMPUNCOMPRESSED.FDB
<... skipped ...>
Analyzing database pages ...
T (128)
    Primary pointer page: 148, Index root page: 149
     Average record length: 73.00 , total records: 100000
    Average version length: 0.00, total versions: 0, max versions: 0
    Data pages: 1409, data page slots: 1409, average fill: 78%
    Fill distribution:
	 0 - 19% = 0
	20 - 39% = 1
	40 - 59% = 0
	60 - 79% = 1408
	80 - 99% = 0
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37631804
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В каком смысле дорого?Victor MetelitsaУ Oracle и DB2 есть компрессия данных и индексов, но это ОЧЕНЬ дорого.
В каком смысле дорого?
В деньгах.
Но, возможно, несколько сотен тысяч долларов для вас недорого - ну... тогда недорого.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37631810
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovАнатоЛойлицензии коммерческого ПО с такими фичами и под такие объёмы закупать - будет дорого...

Это "коммерческое ПО" туда просто не установится из-за аппаратных требований. Тот же
Firebird использует сжатие как данных так и индексов, но аффтар уже привязался к слону...

Вполне установится и будет нормально работать.

Честно говоря, на DB2 Express-C компрессия (как и многие другие продвинутые фичи) почему-то работает (забыли отключить?), ужимает размер базы раза в два, но официально это не лицензировано, в любой момент могут вспомнить и в очередном фикспаке отключить.

Лучше DB2-шного range clustering (описанного мной в одном из предыдущих писем; возможно, эта фича уже кем-то скопирована, но я об этом не знаю) для того сферического коня в вакууме не существует ничего. Зная ключ, мы сразу знаем страницу, на которой запись - индексы не нужны.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37632564
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидФБ на самом деле жмёт строки при записи на диск.Вот только не строки, а целиком запись сжимается.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37632993
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WildSeryВот только не строки, а целиком запись сжимается.

И не всегда запись целиком - это может быть версия, хранящаяся только в виде дельты.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37635613
Фотография Warstone
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaDimitry SibiryakovНо если желаете остаться в пределах этого раздела - пожалуйста. Индексы в PG включают в
себя не только данные, но и отметки версий. Это делает его индексы больше и менее
эффективными. Поэтому они не влазят в ваше ОЗУ. Выкиньте эту гадость.

Говорят, что FB/IB неспособен на Index only access именно потому, что у индексов нет отметок версий и он вынужден лезть в таблицу тогда, когда DB2 и Oracle легко без этого обходятся. Если PG умеет тоже, ему это в плюс.В 9.2 научится.... там IOS делают (Index Only Scans). Это как-раз, когда если критерии отбора полностью попадают в индекс, то таблица не читается. Читается только индекс.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37636177
WarstoneVictor Metelitsaпропущено...

Говорят, что FB/IB неспособен на Index only access именно потому, что у индексов нет отметок версий и он вынужден лезть в таблицу тогда, когда DB2 и Oracle легко без этого обходятся. Если PG умеет тоже, ему это в плюс.В 9.2 научится.... там IOS делают (Index Only Scans). Это как-раз, когда если критерии отбора полностью попадают в индекс, то таблица не читается. Читается только индекс.
Не критерии отбора, а все извлекаемые данные попадают в индекс.
...
Рейтинг: 0 / 0
Большая таблица, мало RAM
    #37638454
Фотография Warstone
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
все извлекаемые данныеWarstoneпропущено...
В 9.2 научится.... там IOS делают (Index Only Scans). Это как-раз, когда если критерии отбора полностью попадают в индекс, то таблица не читается. Читается только индекс.
Не критерии отбора, а все извлекаемые данные попадают в индекс.Да... В том числе... Это я лопухнулся.
...
Рейтинг: 0 / 0
87 сообщений из 87, показаны все 4 страниц
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Большая таблица, мало RAM
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]