|
Большая таблица, мало 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 |
|
|
start [/forum/topic.php?fid=35&msg=37622523&tid=1552593]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
33ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
2ms |
others: | 12ms |
total: | 151ms |
0 / 0 |