powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Большая таблица, мало RAM
25 сообщений из 87, страница 3 из 4
Большая таблица, мало 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
25 сообщений из 87, страница 3 из 4
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Большая таблица, мало RAM
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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