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

Откуда:
Сообщений: 70
Victor Metelitsa
Загрузите тестовыми данными, да посмотрите. Лично мне кажется, что при такой абстрактной постановке и с миллиардами записей будет терпимо работать (причём даже без партишионирования, но при наличии подходящих индексов). Вот бекапы делать - это да...

Смотрите, провёл простой тест:
1) одна таблица 100 строк, 512М памяти, индексы влазят в память, запрос по id - 5ms
2) одна таблица 1М строк, 512М памяти, индексы влазят в память, запрос по id - 5ms
3) одна таблица 20М строк, 512М памяти, индексы НЕ влазят в память, запрос по id - 150-50ms
Ухудшение в 10 раз.
19 янв 12, 15:59    [11933744]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
thehil
Victor Metelitsa
Загрузите тестовыми данными, да посмотрите. Лично мне кажется, что при такой абстрактной постановке и с миллиардами записей будет терпимо работать (причём даже без партишионирования, но при наличии подходящих индексов). Вот бекапы делать - это да...

Смотрите, провёл простой тест:
1) одна таблица 100 строк, 512М памяти, индексы влазят в память, запрос по id - 5ms
2) одна таблица 1М строк, 512М памяти, индексы влазят в память, запрос по id - 5ms
3) одна таблица 20М строк, 512М памяти, индексы НЕ влазят в память, запрос по id - 150-50ms
Ухудшение в 10 раз.

А теперь напрашивается проверить 200M.
19 янв 12, 16:20    [11933905]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

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

эх... место на VM кончилось, нужно время чтобы пересоздать с большим HDD. Ждите, продолжение следует :)
19 янв 12, 16:25    [11933975]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Dimitry Sibiryakov
Member

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

thehil
3) одна таблица 20М строк, 512М памяти, индексы НЕ влазят в память

Это что за индексы, что они для 20М строк в память не влазят?.. Неужели PostrgreSQL их
совсем никак не сжимает?..

Posted via ActualForum NNTP Server 1.5

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

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

обычный индекс по bigserial на 20М строк занял что-то около 600 Мб
19 янв 12, 16:34    [11934088]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
РСУБД изначально делали в предположении, что все данные в память не влазят. Это сейчас ОЗУ - как грязи. (Посмотрите, кстати, какие сейчас цены на память. Для самосбора можно брать по 8 гиг ECC за 2.5тр - я недавно даже вообразить такое не мог).

Чтение одной страницы - ну, где-то 10-15ms на позиционирование головки и 0.1ms собственно на считывание 8-килобайтного блока, это для дешёвых SATA-шных винчестеров. Поиск в индексе - это просто проход через его уровни, то есть считывание нескольких страниц. С ростом величины таблицы количество уровней увеличивается ОЧЕНЬ слабо - я как-то не уверен, повысится ли количество уровней хотя бы на 1 при повышении количества записей в таблице со 20M до 200M.
19 янв 12, 16:37    [11934128]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

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

Т.е. вы предлагаете не заморачиваться и хранить таблицу с милиардами строк, с сотнями гигабайт данных как есть?
19 янв 12, 16:41    [11934171]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
sharding сделать
Guest
thehil
Victor Metelitsa
Загрузите тестовыми данными, да посмотрите. Лично мне кажется, что при такой абстрактной постановке и с миллиардами записей будет терпимо работать (причём даже без партишионирования, но при наличии подходящих индексов). Вот бекапы делать - это да...

Смотрите, провёл простой тест:
1) одна таблица 100 строк, 512М памяти, индексы влазят в память, запрос по id - 5ms
2) одна таблица 1М строк, 512М памяти, индексы влазят в память, запрос по id - 5ms
3) одна таблица 20М строк, 512М памяти, индексы НЕ влазят в память, запрос по id - 150-50ms
Ухудшение в 10 раз.

А теперь попробуйте тот же самый тест с партиционированием. Результаты эквивалентны будут. 150 ms.
Только тот же самый, а не другой.

А вот если sharding сделать, то останется в пределах 5ms.
19 янв 12, 16:55    [11934320]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
thehil
Victor Metelitsa,

Т.е. вы предлагаете не заморачиваться и хранить таблицу с милиардами строк, с сотнями гигабайт данных как есть?

Производительность, как мне кажется, будет удовлетворительной (на тех запросах и в тех рамках,что вы описали), но советую удостовериться лично. И, кроме производительности тех запросов, надо рассматривать другие проблемы (вроде неудобства делания бекапов или пресловутого "вакуума") - имеет смысл провести натурные испытания.
19 янв 12, 17:05    [11934404]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
это без разницы
Guest
Victor Metelitsa
РСУБД изначально делали в предположении, что все данные в память не влазят. Это сейчас ОЗУ - как грязи. (Посмотрите, кстати, какие сейчас цены на память. Для самосбора можно брать по 8 гиг ECC за 2.5тр - я недавно даже вообразить такое не мог).

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

Да, на сервер не сложно поставить 64ГБ.
Но если у него сотни ГБ данных, то это не спасет. Пусть даже индекс влезет, но данные - нет. А это обращение к диску и ухудшение скорости на 2-3 порядка.
Так же не спасет и партиционирование.

Если идет обращение только к 10% записи, то и сервер закжширует только эти 10%, и только на них необходимо будет ОЗУ. С партиционированием или без - это без разницы.
19 янв 12, 17:05    [11934405]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Dimitry Sibiryakov
Member

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

это без разницы
]А это обращение к диску и ухудшение скорости на 2-3 порядка.

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

Posted via ActualForum NNTP Server 1.5

19 янв 12, 17:18    [11934505]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
miksoft
Member

Откуда:
Сообщений: 38919
Dimitry Sibiryakov
это без разницы
А это обращение к диску и ухудшение скорости на 2-3 порядка.
SSD диски - сильная вещь.
Кстати, да!
Мы недавно пробовали Oracle XE на SSD со схожей проблемой - объем данных не влезал в отведенный гиг. Самый тяжелый запрос в приложении вместо 10-30 секунд на обычном SATA-диске (колебалось в зависимости от параметров) стал выполняться за 2-3 секунды на SSD (причем весьма бюджетном, Vortex3 60Гб).
19 янв 12, 17:23    [11934560]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
sharding сделать
Guest
Dimitry Sibiryakov
это без разницы
]А это обращение к диску и ухудшение скорости на 2-3 порядка.

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

Все относительно:
Скорость RAM - 20 000 МБ/сек
Скорость SSD - 300 МБ/сек (SATAII)
Скорость HDD - 100 МБ/сек (Sequetial)
Скорость HDD - 10 МБ/сек (Random)
19 янв 12, 17:29    [11934612]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
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 янв 12, 21:00    [11935913]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
Если кому-нибудь интересно: провёл тестирование pgbench-ем (PostgreSQL), продакшн схемы, продакшн запросом (выборка записи по ID). Результат — как только база достигает размеров памяти производительность резко падает где-то в 50 раз. До скачка — 4000 запросов в секунду, после — 30 до 120 запросов в секунду. Все настройки по-умолчанию (только не надо объяснять что это плохо).
23 янв 12, 19:41    [11955705]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
thehil, ты уже определился, над чем бьёшся: чтобы "скачка после роста БД не было" (ищем чудо-пулю) или чтобы "если в память не влазим, быстродействие должно упасть не ниже конкретного Ч"?

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

Неужели действительно нет критериев, чтобы выделить наиболее востребованную часть БД, а для отсальных запросов сказать, что вы будете выполняться таки за 100мс?
23 янв 12, 20:13    [11955887]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Dimitry Sibiryakov
Member

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

thehil
после — 30 до 120 запросов в секунду

Не верю. Если в кэш не помещается последний уровень индекса, то чтение каждой запись
вызывает чтение одной страницы индекса и одной - данных. Пусть даже действительность хуже
и на каждую запись надо прочитать 4 страницы. Пусть каждая страница 16 килобайт. Умножаем
на 120 запросов в секунду получаем нагрузку на ввод-вывод чуть меньше восьми мегабайт в
секунду. У вас база что, на дискете была?..

Posted via ActualForum NNTP Server 1.5

23 янв 12, 21:29    [11956325]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
Dimitry Sibiryakov
thehil
после — 30 до 120 запросов в секунду

получаем нагрузку на ввод-вывод чуть меньше восьми мегабайт в
секунду



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


вроде сходится :)
23 янв 12, 21:36    [11956367]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
miksoft
Member

Откуда:
Сообщений: 38919
Dimitry Sibiryakov
thehil
после — 30 до 120 запросов в секунду

Не верю. Если в кэш не помещается последний уровень индекса, то чтение каждой запись
вызывает чтение одной страницы индекса и одной - данных. Пусть даже действительность хуже
и на каждую запись надо прочитать 4 страницы. Пусть каждая страница 16 килобайт. Умножаем
на 120 запросов в секунду получаем нагрузку на ввод-вывод чуть меньше восьми мегабайт в
секунду. У вас база что, на дискете была?..
Это же короткие одноблочные чтения, почти для каждого приходится ждать нужного сектора и/или двигать головки диска, так что все нормально.
23 янв 12, 21:42    [11956410]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
А какая у вас ОСь ?

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

vmstat 1 20
для этого случая
thehil
после — 30 до 120 запросов в секунду. Все настройки по-умолчанию (только не надо объяснять что это плохо).
23 янв 12, 21:49    [11956448]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Dimitry Sibiryakov
Member

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

АнатоЛой
вроде сходится :)

Тогда возникает вопрос: зачем PG на каждую запись читает пять страниц?

Posted via ActualForum NNTP Server 1.5

23 янв 12, 21:52    [11956464]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
Dimitry Sibiryakov
АнатоЛой
вроде сходится :)

Тогда возникает вопрос: зачем PG на каждую запись читает пять страниц?

Дык мы ж ничего не знаем ни про железо, ни про версию Pg, ни про настройки Pg, ни про схему БД, ни про физическое расположение файлов БД, ни про запрос, которым ТС в БД долбится, ни про статистику, ни про план выполнения запроса...
А среднепотолочно - похоже :)...
23 янв 12, 21:57    [11956490]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Dimitry Sibiryakov
Member

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

АнатоЛой
мы ж ничего не знаем

Из железа мы знаем 500Мб ОЗУ. Из настроек - всё по дефолту. Из запроса - запись выбирается
по первичному ключу. А в остальном - да, партизанит ТС не на шутку.

Posted via ActualForum NNTP Server 1.5

23 янв 12, 22:03    [11956516]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
Плохо считаете
Guest
Dimitry Sibiryakov
thehil
после — 30 до 120 запросов в секунду

Не верю. Если в кэш не помещается последний уровень индекса, то чтение каждой запись
вызывает чтение одной страницы индекса и одной - данных. Пусть даже действительность хуже
и на каждую запись надо прочитать 4 страницы. Пусть каждая страница 16 килобайт. Умножаем
на 120 запросов в секунду получаем нагрузку на ввод-вывод чуть меньше восьми мегабайт в
секунду. У вас база что, на дискете была?..

Плохо считаете. Считайте не в мегабайтах, а в IOPs.
По вашему сколько один HDD выдает IOPS'ов?
23 янв 12, 22:09    [11956541]     Ответить | Цитировать Сообщить модератору
 Re: Большая таблица, мало RAM  [new]
thehil
Member

Откуда:
Сообщений: 70
Dimitry Sibiryakov
АнатоЛой
мы ж ничего не знаем

Из железа мы знаем 500Мб ОЗУ. Из настроек - всё по дефолту. Из запроса - запись выбирается
по первичному ключу. А в остальном - да, партизанит ТС не на шутку.

Ну что ещё добавить: PG 9.1, тесты производились с фильтром по случайному ID.
23 янв 12, 22:24    [11956635]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить