|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Какие существуют бесплатные решения позволяющие работать с большими таблицами (1 млрд.) на железе с ограниченной RAM. Т.е. когда даже индексы целиком не помещаются в память и невозможно расшардить таблицу на несколько машин. Что можно придумать кроме партицирования чтобы получить хотя бы примерно линейную зависимость производительности от количества строк? При том что даже в случае партицирования могут быть запросы читающие со всех партиций. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 13:55 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilЧто можно придумать кроме партицирования чтобы получить хотя бы примерно линейную зависимость производительности от количества строк? При том что даже в случае партицирования могут быть запросы читающие со всех партиций. Спасибо.А она и так будет линейной в худшем случае. И с очень большим множителем (из-за физического ввода-вывода). Обычно стремятся сделать быстрее, чем линейную. В чем помогают, например, индексы. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 13:59 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehil, Вы огласите задачу более детально. Пока же ничего определенного сказать нельзя. Может, любая СУБД будет одинаково плоха. А может, обычные файлы спасут. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:00 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
И да, аналитики совсем не нужно, больше на OLTP похоже. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:00 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Производительность не будет линейной хотя бы из за того что при небольшом количестве записей индексы влазят в память, при большом - уже ничего не влазит. Доступ к строкам примерно равномерный, нету распределения по времени. Большинство запросов по ПК, часть - по другим индексированным полям. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:03 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilПроизводительность не будет линейной хотя бы из за того что при небольшом количестве записей индексы влазят в память, при большом - уже ничего не влазит.Да, по достижении некоторого порога будет скачок, но за ним картина опять будет той же (с индексом - логарифмическйи рост, без индекса - линейный). ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:11 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
miksoftthehilПроизводительность не будет линейной хотя бы из за того что при небольшом количестве записей индексы влазят в память, при большом - уже ничего не влазит.Да, по достижении некоторого порога будет скачок, но за ним картина опять будет той же (с индексом - логарифмическйи рост, без индекса - линейный). Это и понятно, цель - преодолеть скачок. Мой первый вариант - партицирование, тут можно надеятся на примерно одинаковою производительность при любом числе строк для запросов по ключу партицирования. Но для остальных запросов будет только хуже. Нужны ещё варианты. Причем бесплатные. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:15 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
А партиционирование где бесплатное? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:18 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilЭто и понятно, цель - преодолеть скачок.Никак не преодолете. Либо физический ввод/вывод не нужен (нужные данные есть в ОП), либо нужен. Во втором случае совсем другие времена. Максимум, что в этой ситуации поможет, имхо: 1) правильный алгоритм кэширования, чтобы для наиболее критичных по времени запросов была выше вероятность обойтись данными в ОП. 2) правильное использование индексов и других механизмов СУБД, позволяющие минимизировать физический ввод/вывод. И не вовсе не факт, что партиционирование тут поможет. Пока не описана четко задача - можно теоретизировать бесконечно. Оптимизировать можно только частный случай. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:24 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
В случае Oracle, партишионирование поддерживает только EE - это сотни тысяч долларов на один сервер. С DB2 аналогично. Postgres? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:34 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Victor Metelitsa, Да PostgreSQL поддерживает, да и на крайний случай MySQL тоже может. Насчет подробнестей - уточните что вы ещё хотите услышать? Есть отностительно слабый сервер, из железа больше ничего. Есть таблица с миллионами строк, хочется чтобы разростание до миллиардов не привело к заметному ухудшению времени отклика. Апп сервер на той же машине. Запросов не много, до нескольких в секунду. Запросы элементарные: дай/удали/измени строку по id в основном (80%), немного запросов по другим полям из этой же таблицы, использующие индекс (10%), есть несколько джойнов с такой же большой таблицей по id. Везде индексы и на небольших объёмах данных отклик устраивает. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:43 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehil , А про нелинейную зависимость в OLTP от размера таблицы это вы тестами определили или предположили? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:45 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Была мысль насчет шардинга mongodb на одной машине, но походу это гиблое дело. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:45 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
нелинейную зависимость в OLTP, Предположин, да и люди выше подтвердили. Пока всё в памяти - логарифмически, как только не влазит - должно хуже. Сейчас попробую провести тест в условиях ограниченной памяти. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:47 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilЗапросов не много, до нескольких в секунду.Ну тут и с дисковыми чтениями ничего страшного не будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:47 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilVictor Metelitsa, Да PostgreSQL поддерживает, да и на крайний случай MySQL тоже может. Насчет подробнестей - уточните что вы ещё хотите услышать? Есть отностительно слабый сервер, из железа больше ничего. Есть таблица с миллионами строк, хочется чтобы разростание до миллиардов не привело к заметному ухудшению времени отклика. Апп сервер на той же машине. Запросов не много, до нескольких в секунду. Запросы элементарные: дай/удали/измени строку по id в основном (80%), немного запросов по другим полям из этой же таблицы, использующие индекс (10%), есть несколько джойнов с такой же большой таблицей по id. Везде индексы и на небольших объёмах данных отклик устраивает. Сколько ОЗУ? Какая СУБД? Первые 2-3 уровня индекса будут закэшированы. Партиционирование это фактически ещё один уровень индекса. Здесь удобство бывает в том, что с партициями можно работать как с обычными таблицами и переносить их между тейблспейсами и соотвественно на другие СХД. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:49 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
miksoft, Возможно. Но в любом случае чтение с диска заметно медленнее чем из памяти. В случае с партицирование есть шанс выделить наиболее используемые данные в одну партицию и тогда шанс попадание в кеш индекса для этой партиции должен быть выше. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:51 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilнелинейную зависимость в OLTP, Предположин, да и люди выше подтвердили. Пока всё в памяти - логарифмически, как только не влазит - должно хуже. Сейчас попробую провести тест в условиях ограниченной памяти. Если подтвердиться то только шардинг, кластер или добавлять памяти. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:52 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilmiksoft, Возможно. Но в любом случае чтение с диска заметно медленнее чем из памяти. В случае с партицирование есть шанс выделить наиболее используемые данные в одну партицию и тогда шанс попадание в кеш индекса для этой партиции должен быть выше. Попробуйте "провести тест в условиях ограниченной памяти." и если будут ухудшения, то попробуйте от них избавиться "выделить наиболее используемые данные в одну партицию и тогда шанс попадание в кеш индекса для этой партиции должен быть выше.". ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:54 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Сколько ОЗУ? Какая СУБД?Сколько ОЗУ? Какая СУБД? Первые 2-3 уровня индекса будут закэшированы. Партиционирование это фактически ещё один уровень индекса. Здесь удобство бывает в том, что с партициями можно работать как с обычными таблицами и переносить их между тейблспейсами и соотвественно на другие СХД. Сейчас PostgreSQL, но возможно поменять на абсолютно любую бесплатную. ОЗУ может меняться, т.к. приложение целиком с базой ставится на клиентский сервер. Давайте предположим что минимум 4 Gb ОЗУ. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:54 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
нелинейную зависимость в OLTPthehilнелинейную зависимость в OLTP, Предположин, да и люди выше подтвердили. Пока всё в памяти - логарифмически, как только не влазит - должно хуже. Сейчас попробую провести тест в условиях ограниченной памяти. Если подтвердиться то только шардинг, кластер или добавлять памяти. К сожалению все эти варианты сразу отпадают. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:55 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilmiksoft, Возможно. Но в любом случае чтение с диска заметно медленнее чем из памяти.Пока не озвучены четкие цифры вида "такой-то SQL-запрос на таких-то данных отрабывает за X секунд, а допустимо не более чем за Y секунд в Z% случаев" ваши фразы типа "заметно медленнее" - ни о чем. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:55 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Victor MetelitsaВ случае Oracle, партишионирование поддерживает только EE - это сотни тысяч долларов на один сервер. С DB2 аналогично. Partition Views есть в любой оракловой редакции http://docs.oracle.com/cd/A57673_01/DOC/server/doc/A48506/partview.htm#351 в постгрес взрослого партитионинга нет, но есть те же самые Partition Views ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 14:58 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilЕсть отностительно слабый сервер, из железа больше ничего. Есть таблица с миллионами строк, хочется чтобы разростание до миллиардов не привело к заметному ухудшению времени отклика. Апп сервер на той же машине. Запросов не много, до нескольких в секунду. Запросы элементарные: дай/удали/измени строку по id в основном (80%), немного запросов по другим полям из этой же таблицы, использующие индекс (10%), есть несколько джойнов с такой же большой таблицей по id. Везде индексы и на небольших объёмах данных отклик устраивает. Загрузите тестовыми данными, да посмотрите. Лично мне кажется, что при такой абстрактной постановке и с миллиардами записей будет терпимо работать (причём даже без партишионирования, но при наличии подходящих индексов). Вот бекапы делать - это да... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 15:01 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Yo.!Victor MetelitsaВ случае Oracle, партишионирование поддерживает только EE - это сотни тысяч долларов на один сервер. С DB2 аналогично. Partition Views есть в любой оракловой редакции http://docs.oracle.com/cd/A57673_01/DOC/server/doc/A48506/partview.htm#351 А... Я уже забыл про эту фичу (в DB2 такое можно также на любых версиях) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 15:09 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Victor MetelitsaЗагрузите тестовыми данными, да посмотрите. Лично мне кажется, что при такой абстрактной постановке и с миллиардами записей будет терпимо работать (причём даже без партишионирования, но при наличии подходящих индексов). Вот бекапы делать - это да... Смотрите, провёл простой тест: 1) одна таблица 100 строк, 512М памяти, индексы влазят в память, запрос по id - 5ms 2) одна таблица 1М строк, 512М памяти, индексы влазят в память, запрос по id - 5ms 3) одна таблица 20М строк, 512М памяти, индексы НЕ влазят в память, запрос по id - 150-50ms Ухудшение в 10 раз. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 15:59 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilVictor MetelitsaЗагрузите тестовыми данными, да посмотрите. Лично мне кажется, что при такой абстрактной постановке и с миллиардами записей будет терпимо работать (причём даже без партишионирования, но при наличии подходящих индексов). Вот бекапы делать - это да... Смотрите, провёл простой тест: 1) одна таблица 100 строк, 512М памяти, индексы влазят в память, запрос по id - 5ms 2) одна таблица 1М строк, 512М памяти, индексы влазят в память, запрос по id - 5ms 3) одна таблица 20М строк, 512М памяти, индексы НЕ влазят в память, запрос по id - 150-50ms Ухудшение в 10 раз. А теперь напрашивается проверить 200M. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 16:20 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Victor Metelitsa, эх... место на VM кончилось, нужно время чтобы пересоздать с большим HDD. Ждите, продолжение следует :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 16:25 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehil3) одна таблица 20М строк, 512М памяти, индексы НЕ влазят в память Это что за индексы, что они для 20М строк в память не влазят?.. Неужели PostrgreSQL их совсем никак не сжимает?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 16:31 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, обычный индекс по bigserial на 20М строк занял что-то около 600 Мб ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 16:34 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
РСУБД изначально делали в предположении, что все данные в память не влазят. Это сейчас ОЗУ - как грязи. (Посмотрите, кстати, какие сейчас цены на память. Для самосбора можно брать по 8 гиг ECC за 2.5тр - я недавно даже вообразить такое не мог). Чтение одной страницы - ну, где-то 10-15ms на позиционирование головки и 0.1ms собственно на считывание 8-килобайтного блока, это для дешёвых SATA-шных винчестеров. Поиск в индексе - это просто проход через его уровни, то есть считывание нескольких страниц. С ростом величины таблицы количество уровней увеличивается ОЧЕНЬ слабо - я как-то не уверен, повысится ли количество уровней хотя бы на 1 при повышении количества записей в таблице со 20M до 200M. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 16:37 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Victor Metelitsa, Т.е. вы предлагаете не заморачиваться и хранить таблицу с милиардами строк, с сотнями гигабайт данных как есть? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 16:41 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilVictor MetelitsaЗагрузите тестовыми данными, да посмотрите. Лично мне кажется, что при такой абстрактной постановке и с миллиардами записей будет терпимо работать (причём даже без партишионирования, но при наличии подходящих индексов). Вот бекапы делать - это да... Смотрите, провёл простой тест: 1) одна таблица 100 строк, 512М памяти, индексы влазят в память, запрос по id - 5ms 2) одна таблица 1М строк, 512М памяти, индексы влазят в память, запрос по id - 5ms 3) одна таблица 20М строк, 512М памяти, индексы НЕ влазят в память, запрос по id - 150-50ms Ухудшение в 10 раз. А теперь попробуйте тот же самый тест с партиционированием. Результаты эквивалентны будут. 150 ms. Только тот же самый, а не другой. А вот если sharding сделать, то останется в пределах 5ms. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 16:55 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilVictor Metelitsa, Т.е. вы предлагаете не заморачиваться и хранить таблицу с милиардами строк, с сотнями гигабайт данных как есть? Производительность, как мне кажется, будет удовлетворительной (на тех запросах и в тех рамках,что вы описали), но советую удостовериться лично. И, кроме производительности тех запросов, надо рассматривать другие проблемы (вроде неудобства делания бекапов или пресловутого "вакуума") - имеет смысл провести натурные испытания. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 17:05 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Victor MetelitsaРСУБД изначально делали в предположении, что все данные в память не влазят. Это сейчас ОЗУ - как грязи. (Посмотрите, кстати, какие сейчас цены на память. Для самосбора можно брать по 8 гиг ECC за 2.5тр - я недавно даже вообразить такое не мог). Чтение одной страницы - ну, где-то 10-15ms на позиционирование головки и 0.1ms собственно на считывание 8-килобайтного блока, это для дешёвых SATA-шных винчестеров. Поиск в индексе - это просто проход через его уровни, то есть считывание нескольких страниц. С ростом величины таблицы количество уровней увеличивается ОЧЕНЬ слабо - я как-то не уверен, повысится ли количество уровней хотя бы на 1 при повышении количества записей в таблице со 20M до 200M. Да, на сервер не сложно поставить 64ГБ. Но если у него сотни ГБ данных, то это не спасет. Пусть даже индекс влезет, но данные - нет. А это обращение к диску и ухудшение скорости на 2-3 порядка. Так же не спасет и партиционирование. Если идет обращение только к 10% записи, то и сервер закжширует только эти 10%, и только на них необходимо будет ОЗУ. С партиционированием или без - это без разницы. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 17:05 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
это без разницы]А это обращение к диску и ухудшение скорости на 2-3 порядка. SSD диски - сильная вещь. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 17:18 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovэто без разницыА это обращение к диску и ухудшение скорости на 2-3 порядка.SSD диски - сильная вещь.Кстати, да! Мы недавно пробовали Oracle XE на SSD со схожей проблемой - объем данных не влезал в отведенный гиг. Самый тяжелый запрос в приложении вместо 10-30 секунд на обычном SATA-диске (колебалось в зависимости от параметров) стал выполняться за 2-3 секунды на SSD (причем весьма бюджетном, Vortex3 60Гб). ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 17:23 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovэто без разницы]А это обращение к диску и ухудшение скорости на 2-3 порядка. SSD диски - сильная вещь. Все относительно: Скорость RAM - 20 000 МБ/сек Скорость SSD - 300 МБ/сек (SATAII) Скорость HDD - 100 МБ/сек (Sequetial) Скорость HDD - 10 МБ/сек (Random) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 17:29 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
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 нет нужды позиционировать головки, за неимением таковых. Поэтому на чтение реальная разница на произвольном доступе фантастическая. Но ведь они и дорогие очень, особенно "ентерпрайзные", надёжность... подозрительная, да и с записью совсем не так хорошо. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.01.2012, 21:00 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Если кому-нибудь интересно: провёл тестирование pgbench-ем (PostgreSQL), продакшн схемы, продакшн запросом (выборка записи по ID). Результат — как только база достигает размеров памяти производительность резко падает где-то в 50 раз. До скачка — 4000 запросов в секунду, после — 30 до 120 запросов в секунду. Все настройки по-умолчанию (только не надо объяснять что это плохо). ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2012, 19:41 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehil, ты уже определился, над чем бьёшся: чтобы "скачка после роста БД не было" (ищем чудо-пулю) или чтобы "если в память не влазим, быстродействие должно упасть не ниже конкретного Ч"? По определению, если в память не влазим - будет медленнее, потому что если с винта можно брать чудо-алгоритмом, то из памяти можно сделать то же самое - но гораздо быстрее :) :(. Повышение быстродействия ПО с использованием конкретной БД обычно и сводится к тому, чтобы для большинства запросов нужная информация бралась из кеша в ОЗУ, а не с диска.. Вариант: ускорить винт, но SSD (твердотельные накопители) уже предлагали... Если при прочих равных (на том же железе), то остаётся только средствами администрирования оптимизировать работу СУБД, ПО или улучшить схему хранения данных... Неужели действительно нет критериев, чтобы выделить наиболее востребованную часть БД, а для отсальных запросов сказать, что вы будете выполняться таки за 100мс? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2012, 20:13 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilпосле — 30 до 120 запросов в секунду Не верю. Если в кэш не помещается последний уровень индекса, то чтение каждой запись вызывает чтение одной страницы индекса и одной - данных. Пусть даже действительность хуже и на каждую запись надо прочитать 4 страницы. Пусть каждая страница 16 килобайт. Умножаем на 120 запросов в секунду получаем нагрузку на ввод-вывод чуть меньше восьми мегабайт в секунду. У вас база что, на дискете была?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2012, 21:29 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovthehilпосле — 30 до 120 запросов в секунду получаем нагрузку на ввод-вывод чуть меньше восьми мегабайт в секунду sharding сделатьСкорость HDD - 10 МБ/сек (Random) вроде сходится :) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2012, 21:36 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovthehilпосле — 30 до 120 запросов в секунду Не верю. Если в кэш не помещается последний уровень индекса, то чтение каждой запись вызывает чтение одной страницы индекса и одной - данных. Пусть даже действительность хуже и на каждую запись надо прочитать 4 страницы. Пусть каждая страница 16 килобайт. Умножаем на 120 запросов в секунду получаем нагрузку на ввод-вывод чуть меньше восьми мегабайт в секунду. У вас база что, на дискете была?.. Это же короткие одноблочные чтения, почти для каждого приходится ждать нужного сектора и/или двигать головки диска, так что все нормально. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2012, 21:42 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
А какая у вас ОСь ? Если что то unix -подобное покажите vmstat 1 20 для этого случая thehil после — 30 до 120 запросов в секунду. Все настройки по-умолчанию (только не надо объяснять что это плохо). ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2012, 21:49 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
АнатоЛойвроде сходится :) Тогда возникает вопрос: зачем PG на каждую запись читает пять страниц? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2012, 21:52 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovАнатоЛойвроде сходится :) Тогда возникает вопрос: зачем PG на каждую запись читает пять страниц? Дык мы ж ничего не знаем ни про железо, ни про версию Pg, ни про настройки Pg, ни про схему БД, ни про физическое расположение файлов БД, ни про запрос, которым ТС в БД долбится, ни про статистику, ни про план выполнения запроса... А среднепотолочно - похоже :)... ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2012, 21:57 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
АнатоЛоймы ж ничего не знаем Из железа мы знаем 500Мб ОЗУ. Из настроек - всё по дефолту. Из запроса - запись выбирается по первичному ключу. А в остальном - да, партизанит ТС не на шутку. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2012, 22:03 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovthehilпосле — 30 до 120 запросов в секунду Не верю. Если в кэш не помещается последний уровень индекса, то чтение каждой запись вызывает чтение одной страницы индекса и одной - данных. Пусть даже действительность хуже и на каждую запись надо прочитать 4 страницы. Пусть каждая страница 16 килобайт. Умножаем на 120 запросов в секунду получаем нагрузку на ввод-вывод чуть меньше восьми мегабайт в секунду. У вас база что, на дискете была?.. Плохо считаете. Считайте не в мегабайтах, а в IOPs. По вашему сколько один HDD выдает IOPS'ов? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2012, 22:09 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovАнатоЛоймы ж ничего не знаем Из железа мы знаем 500Мб ОЗУ. Из настроек - всё по дефолту. Из запроса - запись выбирается по первичному ключу. А в остальном - да, партизанит ТС не на шутку. Ну что ещё добавить: PG 9.1, тесты производились с фильтром по случайному ID. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2012, 22:24 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilНу что ещё добавить: PG 9.1, тесты производились с фильтром по случайному ID. Система unix (тестировалось на ubuntu 11.10). ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2012, 22:25 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilНу что ещё добавить Да как обычно: DDL, план, статистику использованного индекса и как уже сказали - результат iostat. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2012, 22:39 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilЕсли кому-нибудь интересно: провёл тестирование pgbench-ем (PostgreSQL), продакшн схемы, продакшн запросом (выборка записи по ID). Результат — как только база достигает размеров памяти производительность резко падает где-то в 50 раз. До скачка — 4000 запросов в секунду, после — 30 до 120 запросов в секунду. Все настройки по-умолчанию (только не надо объяснять что это плохо). А как дела с миллиардом записей? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.01.2012, 23:22 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Victor Metelitsaпосле — 30 до 120 запросов в секунду. Все настройки по-умолчанию (только не надо объяснять что это плохо). А как дела с миллиардом записей?[/quot] ТС, это Victor Metelitsa или ваше упорство проверяет, или намекает, что по сравнению с последним проверенным вариантом производительность будет падать не катастрофично. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 00:33 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Пардон, квотирование слетело ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 00:35 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovАнатоЛоймы ж ничего не знаем Из железа мы знаем 500Мб ОЗУ. Ничего не изменилось бы в постановке вопроса, будь там 2 GB или 16 GB. Из настроек - всё по дефолту. Версия сервера была неизвестна - так что это тоже вилами по воде. Из запроса - запись выбирается по первичному ключу. Какого размера запись - нам всё равно, правда А в остальном - да, партизанит ТС не на шутку. Так отож. Решил, что за бесплатно должно существовать решение проблемы, а все остальные просто так мучаются. Или что ну не может жизнь быть такой сложной :) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 00:50 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
АнатоЛойТС, это Victor Metelitsa или ваше упорство проверяет, или намекает, что по сравнению с последним проверенным вариантом производительность будет падать не катастрофично. На самом деле, вопрос не настолько очевиден, как мне казалось поначалу. Потому что среднее время на позиционирование головок может заметно возрасти с увеличением объёма данных (головкам приходится перемещаться на большее расстояние), так что, хотя само количество чтений на поиск одной записи может возрасти незначительно, зато количество чтений в секунду может заметно упасть. Вот одна из причин, почему я считаю очень важным проверять предположения на практике. Натурные испытания могут помочь выявить важные тонкости. Но сейчас у меня нет "свободного" "железа" под такой тест. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 01:25 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
АнатоЛойDimitry Sibiryakovпропущено... Из железа мы знаем 500Мб ОЗУ. Ничего не изменилось бы в постановке вопроса, будь там 2 GB или 16 GB. Из настроек - всё по дефолту. Версия сервера была неизвестна - так что это тоже вилами по воде. Из запроса - запись выбирается по первичному ключу. Какого размера запись - нам всё равно, правда А в остальном - да, партизанит ТС не на шутку. Так отож. Решил, что за бесплатно должно существовать решение проблемы, а все остальные просто так мучаются. Или что ну не может жизнь быть такой сложной :) Я решил что возможно кто-то уже сталкивался в жизни с подобным и сможет помочь советом или сказать что решения нету. Могу добавить вот что: железо неизвестно и более того оно может варьироваться в хоед работы (виртуальный сервак в амазоне может уменьшать размер памяти и цпу по достижении лимитов). В чём я вижу возможный плюс партицирования: теоретически какая-то часть данных будет использоваться чаще (хоть на десяток процентов но всё же), если выделить эту часть в отдельную партицию - больше шансов что нужный индекс и данные не будут выталкиваться из памяти. Я опять не прав? Может существуют какие-то другие СУБД которые позволяют быстро искать в большом массиве данных не опираясь на память? Понимаю, что это из области фантастики (тут либо читать из памяти, либо с диска) но всё же. Может есть продукт который нацелен именно на это (особая организация данных на диске или индексов или всерх интеллектуальное кеширование)? Пока план - провести тесты с учётом партицирования и настройками сервера, дальше - пытаться оптимизировать даннные, чтобы максимально уменьшить размер строки и таблиц вцелом. Ещё предложения? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 20:05 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehilЕщё предложения? Пойти в раздел PG чтобы тебе помогли понять почему он тормозит. Немного зная работу Firebird изнутри, я могу сказать, что для неё подобная производительность на вышеприведённых примерах была бы подозрительно низкой. Как я уже сказал: чтобы так тормозить, нужно читать по пять страниц на запись. Это лишко. Как минимум два первых уровня индекса должны были влезть в кэш по-любому. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 20:31 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
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.
Создаётся таблица xxx на 1000000000 строк. Размер строки фиксированный (стало быть, под поле v всегда выделено 100 байтов плюс оверхед, хоть это и varchar), место на диске под все 1000000000 выделяется сразу. Для запросов вида Код: sql 1.
индексы не нужны, потому что по ключу легко вычисляется смещение. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 20:52 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Но если желаете остаться в пределах этого раздела - пожалуйста. Индексы в PG включают в себя не только данные, но и отметки версий. Это делает его индексы больше и менее эффективными. Поэтому они не влазят в ваше ОЗУ. Выкиньте эту гадость. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 20:54 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovНо если желаете остаться в пределах этого раздела - пожалуйста. Индексы в PG включают в себя не только данные, но и отметки версий. Это делает его индексы больше и менее эффективными. Поэтому они не влазят в ваше ОЗУ. Выкиньте эту гадость. Говорят, что FB/IB неспособен на Index only access именно потому, что у индексов нет отметок версий и он вынужден лезть в таблицу тогда, когда DB2 и Oracle легко без этого обходятся. Если PG умеет тоже, ему это в плюс. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 20:59 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehil Я решил что возможно кто-то уже сталкивался в жизни с подобным и сможет помочь советом или сказать что решения нету.Вы пытаетесь найти черную кошку в темной комнате т.е. найти идеальное решение вообще . thehil В чём я вижу возможный плюс партицирования: теоретически какая-то часть данных будет использоваться чащеОтвет неверный. Плюс партиционирования в том, чтобы в результате административных действий (заливка, переиндексация, обновление ...) простой был бы только для тех, кто трогает эту партицию, а не для всех. thehil какая-то часть данных будет использоваться чаще Доступ идет поблочно. Чаще используемые блоки по-любому будут в ОЗУ. thehil Может существуют какие-то другие СУБД которые позволяют быстро искать в большом массиве данных не опираясь на память? Найдя волшебную СУБД ХХХ умеющую сверхбыстро делать ваш поиск, вы можете СУЩЕСТВЕННО проиграть в других областях. Бесплтатных ланчей не бывает. thehil Пока план - провести тесты с учётом партицирования и настройками сервера, дальше - пытаться оптимизировать даннные, чтобы максимально уменьшить размер строки и таблиц вцелом. Ещё предложения?Танцевать от печки как предлагали в первых постах топика. То есть - кто ваши пользователи, как часто будут запросы, сколько во времени отклика занимает именно поиск блока (а не соединение, аутентификация, парсинг запроса и т.д.).? Есть ли возможность разделить пользователей во времени/пространстве (каждому пользователю свой сервер Как происходит обновление инфы? Если требования ко времени отклика очень жесткие, то почему заказчик не может тупо добавить железа (это гораздо проще понятнее надежнее) Хрустальный шар мне подсказывает что вы оптимизируете коробочное решение для наислабейшего железа, максимально возможного размера базы, при пике пользовательской активности и минимальных усилиях администратора. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 21:01 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Victor MetelitsaГоворят, что FB/IB неспособен на Index only access именно потому, что у индексов нет отметок версий и он вынужден лезть в таблицу тогда, когда DB2 и Oracle легко без этого обходятся. Если PG умеет тоже, ему это в плюс. В данном случае - в минус, поскольку ему приходится лезть на диск не только за данными но и индексом. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 21:02 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovVictor MetelitsaГоворят, что FB/IB неспособен на Index only access именно потому, что у индексов нет отметок версий и он вынужден лезть в таблицу тогда, когда DB2 и Oracle легко без этого обходятся. Если PG умеет тоже, ему это в плюс. В данном случае - в минус, поскольку ему приходится лезть на диск не только за данными но и индексом. Мы ведь не знаем, за какими данными он лезет, а также других вещей кучу. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 21:06 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Victor MetelitsaМы ведь не знаем, за какими данными он лезет Нет, я, конечно, тоже о ТСе не лучшего мнения, но подозревать, что он делает выборки типа Код: sql 1.
Это означает напрямую назвать его идиотом. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 21:11 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, Ладно, раз разговор перетекает в такое русло, то на этом закончим. Всем спасибо! Буду оптимизировать своего сферического коня в вакууме сам. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 21:21 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
SERG1257thehil В чём я вижу возможный плюс партицирования: теоретически какая-то часть данных будет использоваться чаще Ответ неверный. Плюс партиционирования в том, чтобы в результате административных действий (заливка, переиндексация, обновление ...) простой был бы только для тех, кто трогает эту партицию, а не для всех. Эээ... Это касается исключительно Pg? Потому что в Informix, к примеру, партиционирование и партиции (там оно исторически называется fragmentation и fragments) учитывается оптимизатором и может использоваться для повышения производительности запросов. Например, 1) размазывая строки одной таблицы по разным дискам, позволяет расширить узкое горлышко дискового ввода-вывода... 2) статистика для партиций ведётся отдельно, что повышает её точность... 3) индексы тоже могут быть партиционированы и могут храниться с размером страницы, отличным от размера страницы таблицы etc... ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 21:26 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
АнатоЛой Потому что в Informix, к примеру, партиционирование и партиции (там оно исторически называется fragmentation и fragments) учитывается оптимизатором и может использоваться для повышения производительности запросов.Все так, СУБД знает от этом факте (партиции) и выжимает из этого все, что можно. Однако я утверждаю, что это сопутствующий бонус к улучшенной управляемости для больших баз. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 22:27 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehil Буду оптимизировать своего сферического коня в вакууме сам. Флаг в руки, барабан на шею. Просто возможна ситуация, когда вы разработаете сложный, хитрый алгоритм (найдете экзотическую СУБД) показывающий чудеса производительности на ваших тестах, а реальный заказчик добавит памяти, поставит крутую СХД, разведет пользователей по нодам, нивелируя ваш алгоритм, но будет плеваться работая с вашими вывертами. http://ru.wikipedia.org/wiki/KISS_(принцип) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.01.2012, 22:43 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
SERG1257Флаг в руки, барабан на шею. Откуда столько агресивности? Если готовы сказать по делу — говорите, пустозвонства не надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 00:30 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
thehil Откуда столько агресивности? Желаю удачи. Так лучше? А по сути то же самое. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 00:36 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Victor MetelitsaУ Oracle и DB2 есть компрессия данных и индексов, но это ОЧЕНЬ дорого. В каком смысле дорого? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 14:33 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Victor MetelitsaУ Oracle и DB2 есть компрессия данных и индексов, но это ОЧЕНЬ дорого. У IBM Informix тоже есть. В каком смысле дорого?В каком смысле дорого? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 14:37 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
В каком смысле дорого?В каком смысле дорого? Наверное в том, что раз ТС не может память расширять под свои проблемы, то лицензии коммерческого ПО с такими фичами и под такие объёмы закупать - будет дорого... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 14:39 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
АнатоЛойлицензии коммерческого ПО с такими фичами и под такие объёмы закупать - будет дорого... Это "коммерческое ПО" туда просто не установится из-за аппаратных требований. Тот же Firebird использует сжатие как данных так и индексов, но аффтар уже привязался к слону... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 14:59 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovАнатоЛойлицензии коммерческого ПО с такими фичами и под такие объёмы закупать - будет дорого... Это "коммерческое ПО" туда просто не установится из-за аппаратных требований. Тот же Firebird использует сжатие как данных так и индексов, но аффтар уже привязался к слону... Ну у Firebird сжатие это сильно сказано :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 15:00 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
сильно сказаноНу у Firebird сжатие это сильно сказано :)А что же это? Это не сжатие, или существует другой, специальный термин? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 17:09 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
WildSeryсильно сказаноНу у Firebird сжатие это сильно сказано :)А что же это? Это не сжатие, или существует другой, специальный термин? Поле varchar2(100) - это тоже сжатие, занимает обычно меньше 100. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 17:52 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
сильно сказаноНу у Firebird сжатие это сильно сказано :)ФБ на самом деле жмёт строки при записи на диск. Вот простая иллюстрация: 1) скрипт для заполнения базы плохо сжимаемыми данными: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
2) скрипт для заполнения базы строками вида "аааа...ааа": Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Создаем и заполняем по этим скриптам две базы : Код: plaintext 1. 2. 3. 4.
Смотрим размеры файлов: Код: plaintext 1. 2.
Статистика по заполнению страниц для этих баз: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 18:21 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
В каком смысле дорого?Victor MetelitsaУ Oracle и DB2 есть компрессия данных и индексов, но это ОЧЕНЬ дорого. В каком смысле дорого? В деньгах. Но, возможно, несколько сотен тысяч долларов для вас недорого - ну... тогда недорого. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 23:10 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovАнатоЛойлицензии коммерческого ПО с такими фичами и под такие объёмы закупать - будет дорого... Это "коммерческое ПО" туда просто не установится из-за аппаратных требований. Тот же Firebird использует сжатие как данных так и индексов, но аффтар уже привязался к слону... Вполне установится и будет нормально работать. Честно говоря, на DB2 Express-C компрессия (как и многие другие продвинутые фичи) почему-то работает (забыли отключить?), ужимает размер базы раза в два, но официально это не лицензировано, в любой момент могут вспомнить и в очередном фикспаке отключить. Лучше DB2-шного range clustering (описанного мной в одном из предыдущих писем; возможно, эта фича уже кем-то скопирована, но я об этом не знаю) для того сферического коня в вакууме не существует ничего. Зная ключ, мы сразу знаем страницу, на которой запись - индексы не нужны. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.01.2012, 23:19 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
ТаблоидФБ на самом деле жмёт строки при записи на диск.Вот только не строки, а целиком запись сжимается. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2012, 12:40 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
WildSeryВот только не строки, а целиком запись сжимается. И не всегда запись целиком - это может быть версия, хранящаяся только в виде дельты. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
26.01.2012, 14:51 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
Victor MetelitsaDimitry SibiryakovНо если желаете остаться в пределах этого раздела - пожалуйста. Индексы в PG включают в себя не только данные, но и отметки версий. Это делает его индексы больше и менее эффективными. Поэтому они не влазят в ваше ОЗУ. Выкиньте эту гадость. Говорят, что FB/IB неспособен на Index only access именно потому, что у индексов нет отметок версий и он вынужден лезть в таблицу тогда, когда DB2 и Oracle легко без этого обходятся. Если PG умеет тоже, ему это в плюс.В 9.2 научится.... там IOS делают (Index Only Scans). Это как-раз, когда если критерии отбора полностью попадают в индекс, то таблица не читается. Читается только индекс. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.01.2012, 17:58 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
WarstoneVictor Metelitsaпропущено... Говорят, что FB/IB неспособен на Index only access именно потому, что у индексов нет отметок версий и он вынужден лезть в таблицу тогда, когда DB2 и Oracle легко без этого обходятся. Если PG умеет тоже, ему это в плюс.В 9.2 научится.... там IOS делают (Index Only Scans). Это как-раз, когда если критерии отбора полностью попадают в индекс, то таблица не читается. Читается только индекс. Не критерии отбора, а все извлекаемые данные попадают в индекс. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.01.2012, 00:07 |
|
Большая таблица, мало RAM
|
|||
---|---|---|---|
#18+
все извлекаемые данныеWarstoneпропущено... В 9.2 научится.... там IOS делают (Index Only Scans). Это как-раз, когда если критерии отбора полностью попадают в индекс, то таблица не читается. Читается только индекс. Не критерии отбора, а все извлекаемые данные попадают в индекс.Да... В том числе... Это я лопухнулся. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2012, 16:12 |
|
|
start [/forum/topic.php?all=1&fid=35&tid=1552593]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
34ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
140ms |
get tp. blocked users: |
2ms |
others: | 238ms |
total: | 459ms |
0 / 0 |