у них много подобных роликов

Причём проплаченных троллей вроде.

только что проплатил мегатролля — Kostya Osipov, создатель Tarantool, очень жду, когда что-то скажет. Костя, не молчи! За что я тебе плачу? Почему тарантул лучше постгреса?

Причём проплаченных троллей вроде.

Якименковских

только что проплатил мегатролля — Kostya Osipov, создатель Tarantool, очень жду, когда что-то скажет. Костя, не молчи! За что я тебе плачу? Почему тарантул лучше постгреса?

Почему флэшка лучше винта?

@kostja_osipov не молчи!

мочему in-memory database лучше постгреса на флешке? :)

*почему

всё серьёзно

мочему in-memory database лучше постгреса на флешке? :)

немного пошаманив можно и postgres сделать in-memory

ой ой, вот тут Костя точно не промолчит

ой ой, вот тут Костя точно не промолчит

надеюсь смог помочь

немного пошаманив можно и postgres сделать in-memory

mount -t tmpfs .... ?

немного пошаманив можно и postgres сделать in-memory

О, у меня так тесты гоняются. Ну почти

если данные не жалко то и unlogged хватит )

mount -t tmpfs .... ?

нет... оставить только shared buffers

г789Пафь

нет... оставить только shared buffers

А pg_xlog куда?

А pg_xlog куда?

в tmp_fs или скипнуть всёравно особо не нужно в этом случае. (малёк код подхачить)

на самом деле интересно, какова скорость записи и апдейтов будет в этом сучае, близко к пропускной способности памяти или нет?

Накладные будут так или иначе, будет медленнее того же редиса, но не на много

Накладные будут так или иначе, будет медленнее того же редиса, но не на много

надеюсь, что так, пока что это конечно на порядки медленее.

совсем не факт что медленее редиса

Чисто в теории, парсинг sql, проверки и прочее

совсем не факт что медленее редиса

медленее, увы даже парсер SQL не самая простая операция.

Чисто в теории, парсинг sql, проверки и прочее

и планировщик...

Prepared statement разве что

ну кстати да. Просто кажется Балашев из майл ру делал тесты на тарантул и чтот как-то не очень хорошо на счет редиса отзывался

Самое время для флейма! Попкорна мне

Ну и можно повспоминать докладчиков некоторых которые прям как Костя жуют по 1 млрд запросов в сутки на постгресе, на одном сервере ;)

(с пгкона зимнего)

это смотря какие запросы...

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

на чтение

У меня 300 млн апдейтов в сутки типа set x = x + 1 кучу проблем порождали.

запись

преаггрегационная

У меня 300 млн апдейтов в сутки типа set x = x + 1 кучу проблем порождали.

статистика? :)

статистика? :)

Она самая, убрали на редис потом.

А млн записей в секунду по 50 байт и синхрониз на 4х серваках, кому-либо удавалось?

Она самая, убрали на редис потом.

оно и верно. В PG имеет смысл потом некую агрегацию уносить.

самое ужасное, update он хуже insert.

самое ужасное, update он хуже insert.

Да-да, мы там чем только не пробовали, fill factor уменьшали, вакуум туда-сюда крутили, etc.

Да-да, мы там чем только не пробовали, fill factor уменьшали, вакуум туда-сюда крутили, etc.

в итоге у вас либо vacuum недогонял либо диски подыхали?

Коля, это что чатик про Редис?-)

Коля, это что чатик про Редис?-)

Это канал про аниме? /\(^_^)/

~(@^_^@)~

в итоге у вас либо vacuum недогонял либо диски подыхали?

Насколько поняли - диски. Был raid10 из 4-х ssd. Ещё периодически вообще как-то странно залипали все эти апдейты - тут мы так и не поняли, что именно было, то ли диски, то ли процессор. Очень много коннектов залипали на ожидании лока строки (потому что 95% там было апдейт одной единственной строки), уменьшили на pgbouncer'ах (там спереди PHP был) количество коннектов к постгресу до примерно равному кол-ву процессоров, и всё стало терпимо на стороне постгреса, но php приходилось ждать на баунсерах подольше своей очереди :)

никакой mvcc конкурентный не даст скорость на апдейте одной строки

ему нужно лок взять и отдать на каждый апдейт

два контекст свитча в архитектуре с воркером на каждый коннект

на каждый апдейт

в тарантуле 300 миллионов апдейтов одной строки пройдут примерно за 300 секунд. на одном ядре.

транзакционно

что вам ещё рассказать про in-memory?

надо почитать сначала, про тарантул)

самое ужасное, update он хуже insert.

Делать только инсерты, 7нф, но больно может быть в логике приложения

что вам ещё рассказать про in-memory?

Да там код не нами писался и под нагрузку такую рассчитан не был:)

Ну что, съели со своим постгресом? :-) Спасибо, Костя

расскажи про acid

минутка рекламы тарантула ? :)

в тарантуле 300 миллионов апдейтов одной строки пройдут примерно за 300 секунд. на одном ядре.

А если больше ядер это как-то в тарантуле может положительно повлиять на апдейт одной строки? Почему так выделили "на одном ядре"?

Потому что никак не может. Строка прибита гвоздями к ядру.

На самом деле было бы круто иметь возможность отключать MVCC и WAL для избранных столбцов при UPDATE именно этогого столбца.

Потому что никак не может. Строка прибита гвоздями к ядру.

Ну вот я так же подумал, но при прочтении по-другому акцент расставился.

ему нужно лок взять и отдать на каждый апдейт

это конечно важно, но сейчас тормозит больше другое...

обожаю dba которые хотят иметь возможность отключать транзакции )

что в этом странного? это аналог UDP

на лог-таблицах я бы тоже отключил

мм... это не аналог udp, потому что udp и tcp работают поверх ip

не вижу как связаны части предложения до и после слова «потому что»

а тут получается что у меня есть tcp поток в котором могут быть udp пакеты

А зачем "финт" с ALTER TABLE .. SET LOGGED / UNLOGGED сделали ?

UDP — кинул данные и забыл, дошли или нет, не знает. что-то без транзакция — то же самое

не то же самое.

гарантия доставки != ACID

а тут получается что у меня есть tcp поток в котором могут быть udp пакеты

ну, я могу и два соединения открыть, почему бы и нет.

не то же самое.

не то же. с метафорами всегда так

если бы гарантия доставки = ACID мы бы давно сидели на CORBA и COM и СУБД были бы никому не нужны

в данном случае соединение всегда одно = журнал транзакций.

либо для нетранзакционных операций вести отдельный журнал, либо его вообще не вести

ну вот у меня в приложении не одно соединение. если было бы ещё +1, меня бы это не сильно взволновало

что мешает положить эти данные в мемкеш?

в (гхм) редис?

семантика та же самая будет

Коллеги, у меня знакомый хотел бы приощиться к PG и в целом работать с БД, но с sql он вообще не работал. Что можно ему посоветовать, начиная с основ ?

А сам постгрес вы со знакомым уже смогли поставить и юзера завести ?

обожаю dba которые хотят иметь возможность отключать транзакции )

А я не dba.

Коллеги, у меня знакомый хотел бы приощиться к PG и в целом работать с БД, но с sql он вообще не работал. Что можно ему посоветовать, начиная с основ ?

Тоже интересно

http://postgrespro.ru/doc/sql.html

Ожидаемо

больше нет ничего )

А сам постгрес вы со знакомым уже смогли поставить и юзера завести ?

Если вопрос к нему - то он полный ноль. Да, я ему ссылку дал на курсы и документацию. Читает, но как я понял ему нужны основы SQL в целом, как устроен язык и.т.д.

В документации к постгресу об этом написано

лучше ему задачу какую-нибудь придумайте, пусть делает ;)