Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
thehil
Ну что ещё добавить: PG 9.1, тесты производились с фильтром по случайному ID.

Система unix (тестировалось на ubuntu 11.10).
23 янв 12, 22:25    [11956650]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54819

thehil
Ну что ещё добавить

Да как обычно: DDL, план, статистику использованного индекса и как уже сказали - результат
iostat.

Posted via ActualForum NNTP Server 1.5

23 янв 12, 22:39    [11956712]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
thehil
Если кому-нибудь интересно: провёл тестирование pgbench-ем (PostgreSQL), продакшн схемы, продакшн запросом (выборка записи по ID). Результат — как только база достигает размеров памяти производительность резко падает где-то в 50 раз. До скачка — 4000 запросов в секунду, после — 30 до 120 запросов в секунду. Все настройки по-умолчанию (только не надо объяснять что это плохо).

А как дела с миллиардом записей?
23 янв 12, 23:22    [11956940]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
Victor Metelitsa
после — 30 до 120 запросов в секунду. Все настройки по-умолчанию (только не надо объяснять что это плохо).

А как дела с миллиардом записей?[/quot]
ТС, это Victor Metelitsa или ваше упорство проверяет, или намекает, что по сравнению с последним проверенным вариантом производительность будет падать не катастрофично.
24 янв 12, 00:33    [11957114]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
Пардон, квотирование слетело
24 янв 12, 00:35    [11957118]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
Dimitry Sibiryakov
АнатоЛой
мы ж ничего не знаем

Из железа мы знаем 500Мб ОЗУ.
Ничего не изменилось бы в постановке вопроса, будь там 2 GB или 16 GB.
Из настроек - всё по дефолту.
Версия сервера была неизвестна - так что это тоже вилами по воде.
Из запроса - запись выбирается по первичному ключу.
Какого размера запись - нам всё равно, правда
А в остальном - да, партизанит ТС не на шутку.
Так отож. Решил, что за бесплатно должно существовать решение проблемы, а все остальные просто так мучаются. Или что ну не может жизнь быть такой сложной :)
24 янв 12, 00:50    [11957155]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
АнатоЛой
ТС, это Victor Metelitsa или ваше упорство проверяет, или намекает, что по сравнению с последним проверенным вариантом производительность будет падать не катастрофично.


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

Вот одна из причин, почему я считаю очень важным проверять предположения на практике. Натурные испытания могут помочь выявить важные тонкости. Но сейчас у меня нет "свободного" "железа" под такой тест.
24 янв 12, 01:25    [11957283]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
АнатоЛой
Dimitry Sibiryakov
пропущено...

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


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

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

Пока план - провести тесты с учётом партицирования и настройками сервера, дальше - пытаться оптимизировать даннные, чтобы максимально уменьшить размер строки и таблиц вцелом. Ещё предложения?

Сообщение было отредактировано: 24 янв 12, 20:12
24 янв 12, 20:05    [11963753]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54819

thehil
Ещё предложения?

Пойти в раздел PG чтобы тебе помогли понять почему он тормозит. Немного зная работу
Firebird изнутри, я могу сказать, что для неё подобная производительность на
вышеприведённых примерах была бы подозрительно низкой. Как я уже сказал: чтобы так
тормозить, нужно читать по пять страниц на запись. Это лишко. Как минимум два первых
уровня индекса должны были влезть в кэш по-любому.

Posted via ActualForum NNTP Server 1.5

24 янв 12, 20:31    [11963877]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
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

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 выделяется сразу. Для запросов вида
  SELECT ... FROM xxx WHERE i=?

индексы не нужны, потому что по ключу легко вычисляется смещение.
24 янв 12, 20:52    [11963961]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54819

Но если желаете остаться в пределах этого раздела - пожалуйста. Индексы в PG включают в
себя не только данные, но и отметки версий. Это делает его индексы больше и менее
эффективными. Поэтому они не влазят в ваше ОЗУ. Выкиньте эту гадость.

Posted via ActualForum NNTP Server 1.5

24 янв 12, 20:54    [11963971]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Dimitry Sibiryakov
Но если желаете остаться в пределах этого раздела - пожалуйста. Индексы в PG включают в
себя не только данные, но и отметки версий. Это делает его индексы больше и менее
эффективными. Поэтому они не влазят в ваше ОЗУ. Выкиньте эту гадость.

Говорят, что FB/IB неспособен на Index only access именно потому, что у индексов нет отметок версий и он вынужден лезть в таблицу тогда, когда DB2 и Oracle легко без этого обходятся. Если PG умеет тоже, ему это в плюс.
24 янв 12, 20:59    [11963988]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
SERG1257
Member

Откуда:
Сообщений: 2933
thehil
Я решил что возможно кто-то уже сталкивался в жизни с подобным и сможет помочь советом или сказать что решения нету.
Вы пытаетесь найти черную кошку в темной комнате т.е. найти идеальное решение вообще.
thehil
В чём я вижу возможный плюс партицирования: теоретически какая-то часть данных будет использоваться чаще
Ответ неверный. Плюс партиционирования в том, чтобы в результате административных действий (заливка, переиндексация, обновление ...) простой был бы только для тех, кто трогает эту партицию, а не для всех.
thehil
какая-то часть данных будет использоваться чаще
Доступ идет поблочно. Чаще используемые блоки по-любому будут в ОЗУ.
thehil
Может существуют какие-то другие СУБД которые позволяют быстро искать в большом массиве данных не опираясь на память?
Найдя волшебную СУБД ХХХ умеющую сверхбыстро делать ваш поиск, вы можете СУЩЕСТВЕННО проиграть в других областях. Бесплтатных ланчей не бывает.

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

Хрустальный шар мне подсказывает что вы оптимизируете коробочное решение для наислабейшего железа, максимально возможного размера базы, при пике пользовательской активности и минимальных усилиях администратора.
24 янв 12, 21:01    [11963992]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54819

Victor Metelitsa
Говорят, что FB/IB неспособен на Index only access именно потому, что у индексов нет
отметок версий и он вынужден лезть в таблицу тогда, когда DB2 и Oracle легко без этого
обходятся. Если PG умеет тоже, ему это в плюс.

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

Posted via ActualForum NNTP Server 1.5

24 янв 12, 21:02    [11963999]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Dimitry Sibiryakov
Victor Metelitsa
Говорят, что FB/IB неспособен на Index only access именно потому, что у индексов нет
отметок версий и он вынужден лезть в таблицу тогда, когда DB2 и Oracle легко без этого
обходятся. Если PG умеет тоже, ему это в плюс.

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

Мы ведь не знаем, за какими данными он лезет, а также других вещей кучу.
24 янв 12, 21:06    [11964014]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54819

Victor Metelitsa
Мы ведь не знаем, за какими данными он лезет

Нет, я, конечно, тоже о ТСе не лучшего мнения, но подозревать, что он делает выборки типа
select ID from T where ID=123


Это означает напрямую назвать его идиотом.

Posted via ActualForum NNTP Server 1.5

24 янв 12, 21:11    [11964036]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
Dimitry Sibiryakov,

Ладно, раз разговор перетекает в такое русло, то на этом закончим. Всем спасибо! Буду оптимизировать своего сферического коня в вакууме сам.
24 янв 12, 21:21    [11964077]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
SERG1257
thehil
В чём я вижу возможный плюс партицирования: теоретически какая-то часть данных будет использоваться чаще

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

Эээ... Это касается исключительно Pg?
Потому что в Informix, к примеру, партиционирование и партиции (там оно исторически называется fragmentation и fragments) учитывается оптимизатором и может использоваться для повышения производительности запросов. Например, 1) размазывая строки одной таблицы по разным дискам, позволяет расширить узкое горлышко дискового ввода-вывода... 2) статистика для партиций ведётся отдельно, что повышает её точность... 3) индексы тоже могут быть партиционированы и могут храниться с размером страницы, отличным от размера страницы таблицы etc...
24 янв 12, 21:26    [11964098]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
SERG1257
Member

Откуда:
Сообщений: 2933
АнатоЛой
Потому что в Informix, к примеру, партиционирование и партиции (там оно исторически называется fragmentation и fragments) учитывается оптимизатором и может использоваться для повышения производительности запросов.
Все так, СУБД знает от этом факте (партиции) и выжимает из этого все, что можно. Однако я утверждаю, что это сопутствующий бонус к улучшенной управляемости для больших баз.
24 янв 12, 22:27    [11964337]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
SERG1257
Member

Откуда:
Сообщений: 2933
thehil
Буду оптимизировать своего сферического коня в вакууме сам.
Флаг в руки, барабан на шею.
Просто возможна ситуация, когда вы разработаете сложный, хитрый алгоритм (найдете экзотическую СУБД) показывающий чудеса производительности на ваших тестах, а реальный заказчик добавит памяти, поставит крутую СХД, разведет пользователей по нодам, нивелируя ваш алгоритм, но будет плеваться работая с вашими вывертами.
http://ru.wikipedia.org/wiki/KISS_(принцип)
24 янв 12, 22:43    [11964384]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
SERG1257
Флаг в руки, барабан на шею.

Откуда столько агресивности? Если готовы сказать по делу — говорите, пустозвонства не надо.
25 янв 12, 00:30    [11964656]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
SERG1257
Member

Откуда:
Сообщений: 2933
thehil
Откуда столько агресивности?
Желаю удачи.

Так лучше? А по сути то же самое.
25 янв 12, 00:36    [11964666]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
В каком смысле дорого?
Guest
Victor Metelitsa
У Oracle и DB2 есть компрессия данных и индексов, но это ОЧЕНЬ дорого.

В каком смысле дорого?
25 янв 12, 14:33    [11968261]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
Victor Metelitsa
У Oracle и DB2 есть компрессия данных и индексов, но это ОЧЕНЬ дорого.

У IBM Informix тоже есть.

В каком смысле дорого?
В каком смысле дорого?
25 янв 12, 14:37    [11968311]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
В каком смысле дорого?
В каком смысле дорого?

Наверное в том, что раз ТС не может память расширять под свои проблемы, то лицензии коммерческого ПО с такими фичами и под такие объёмы закупать - будет дорого...
25 янв 12, 14:39    [11968340]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить