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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

Ну что ещё добавить: PG 9.1, тесты производились с фильтром по случайному ID.
...
Рейтинг: 0 / 0
25 сообщений из 87, страница 2 из 4
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Большая таблица, мало RAM
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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