| Воюем с постгресом дальше... |
[Янв. 28, 2007|07:59 pm] |
Slony I
Поразвлекались с софтинкой для master-slave репликации по имени Slony-I. Лично у меня только стопка матов по этому поводу отложилась. Уровень наколенной поделки, которую в продакшен пускать просто страшно.
Делать репликацию через триггеры, вешаемые на таблицы - это жуть. Изменения в схеме мы отработать не можем, надо вручную делать. Каждая таблица обязана иметь первичный ключ (ну не охренеть ли). Большие объекты вобще не умеем отрабатывать. В общем, спецзаточка БД для организации репликации, чего мне не шибко хочется...
Hot backups (WAL archiving and PITR)
Таки сподвигся на разборку с организацией "горячего" бэкапа БД. Оказалось, что делается все это проще простого, процесс по времени с dump/resore даже сравнивать нельзя, возможность восстановления вплоть до последних транзакций или до любой точки после момента последнего бэкапа (если только WAL-archives остались живыми). В общем, живем и радуемся, начиная с версии 8.0.
В принципе, можно и репликацию таким образом делать, хотя изврат будет редкостный. |
|
|
| Грабли кодировочные... |
[Янв. 25, 2007|12:51 am] |
Веселую тему довелось поколупать сегодня. Началось все с того, что ![[info]](http://p-stat.livejournal.com/img/userinfo.gif) mambaram озадачил логами Slony-I с матюками на кривые данные в базе. Еще через некоторое время показал даже глючную запись из этой базы. Оказалось, что в поле с типом varchar влез символ с кодом 0x80, который в UTF-8 никак не укладывается.
Результаты экспериментов:
1. PostgreSQL 8.1.4 считает, что это корреткный UTF-8.
2. XML::LibXML, работающий через libxml2 тоже все это скушал (данные через него импортировались).
3. utf8::valid() выдал 1 на эту строку.
4. Slony-I, iconv и PgAdmin честно такую ситуацию обругали.
Полезные выводы:
1. Все текстовые данные перед внесением в БД нужно проверять чем-то еще (iconv?).
2. Ежели к целевой кодировке в iconv добавить //IGNORE, то "левые" символы будут просто пропущены (для Text::Iconv действительно).
3. Узнал также про //TRANSLIT в iconv'е, который есть, но не работает.
Мысли:
Неужели в PostgreSQL за такое время нельзя было нормальную поддержку UTF-8 реализовать?.. |
|
|
| Профилируем, блин |
[Авг. 28, 2006|04:08 am] |
И вот нефиг мне было гнать на скорость работы пакета Storable, упустив из башки две вещи:
1. Используется СУБД, торчащая на более слабом тазике у другого ISP.
2. Запросы в хранимые процедуры не загнаны и дпже заранее не компилируются.
Ну не дятел ли?
Все, надо срочно сдавать на доработку напильником кому-то более аккуратному :) |
|
|
| Девелоперское |
[Апр. 20, 2006|08:27 am] |
Примерно до 3:00 занимался программированием на PL/PgSQL.
В результате получилась стопка хранимых функций и процедур,
реализующих основную бизнес-логику нового сервиса.
Быстро, удобно, минимум SQL-кода по скриптам, правки БД задевают только БД. Лепота... |
|
|
| PostgreSQL, Linux, AMD64 |
[Мар. 13, 2006|07:48 pm] |
Итак, теперь у меня есть результаты тестирования PostgreSQL 8.1.3 под Linux 2.6 в 32-битной и 64-битной среде.
Тазик: Dual Opteron 246 2GHz, 2GB RAM, 4xSCSI HDD (RAID 1+0)
Тестировалось штатной софтинкой pgbench:
$ pgbench -U postgres -N -S -s 10 -c 10 -t 3000 test
Результаты в 32-битной среде:
tps = 13604.664767 (including connections establishing)
tps = 13721.643652 (excluding connections establishing)
Результаты в 64-битной среде:
tps = 14533.031886 (including connections establishing)
tps = 14695.494655 (excluding connections establishing)
В общем, прирост заметен и составляет около 7% при переходе на x86_64.
А теперь бум смотреть на JRE для AMD64. |
|
|
| Тазики и софт... |
[Мар. 10, 2006|06:04 pm] |
Есть тазик:
Dual Opteron 246, 2GB RAM, SCSI HDD (RAID 1+0)
Есть задачи:
Нагруженный PostgreSQL + JBoss (JRE 1.5.0)
Спрашивается, стоит ли связываться с 64-битным линухом или ну его нафиг? |
|
|
| То ли лыжи, то ли так и надо... |
[Мар. 5, 2006|09:19 pm] |
Пребываю в состоянии глубокой озадаченности. Будучи сподвигнут Питоном на помощь в сетапе линухового тазика под постгрес, смог выжать чуть больше 5700 транзакций в секунду на тесте имени pgbench. При этом народ вроде как добивался более 10000 TPS на похожем железе.
( А тут подробности ) |
|
|
| |
[Янв. 13, 2006|12:38 pm] |
А EJB3 в Jboss таки делается через Hibernate. Осталось еще покопаться получше с настрокой производительности оного продукта...
А еще я потихоньку проникаюсь наличием в PostgreSQL такой фичи, как Table Partitioning. Хотя и сделано это через ж^hкучу лишних телодвижений, но штука весьма правильная :-) |
|
|
| А таки постгрес рулит |
[Янв. 3, 2006|06:47 pm] |
Создал в PostgreSQL 8.1.1 табличку на 2 млн. записей, проиндексировал.
Выборка по уникальному индексу - 0.9 мс.
Создал еще мелкую табличку.
Создал еще табличку на 14 млн. записей с внешними ключами на первую и на вторую, проиндексировал.
Выборка из трех таблиц заняла 1.3 мс.
Радует такая скорость :)
С кластеризацией и партициями еще не развлекался... |
|
|
| navigation |
| [ |
viewing |
| |
most recent entries |
] |
| |
|
|
sleepy