|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Svyatoslav Abramenkov 2:464/8088.100 21 Mar 2004 10:08:26
To : Maxim Timofeyev
Subject : небольшой POP3-сервер помощнее popa3d
--------------------------------------------------------------------------------
At 21 Mar 04 00:34:18, Maxim Timofeyev wrote to Svyatoslav Abramenkov:
MT>>> 24Mb... Хм. А чего ты на такой крутой машине делаешь?
SA>> Hа этом у моего друга (он сам как раз и занимается базами на
SA>> PostgreSQL) в филиале крутится небольшая база с несколькими тысячами
SA>> записей, канал в центральный офис, и, кажется, samba. Изначально там
SA>> было 16М, я ему помог двумя SIMM по 4М, и там стало 24М, задержка ответа
SA>> на SQL запрос уменьшилась раза в 2-3.
MT> Самому PostgreSQL'ю нужно еще сказать, сколько памяти нужно кушать и
MT> т.п. Тюнинг мне понравился... Статью по тюнингу на форуме sql.ru
MT> подсказали...
Да я от него принес на несколько мегабайт, кажись, всяких статей по
этому поводу, но пока не было нужды читать. А там он, наверное, понастраивал
все, что мог ;-))
MT>>> В смысле была нарушена целостность самих данных или что-то еще?
SA>> Я уже не помню, надо исходники смотреть. Сбивались временные
SA>> метки в поле типа TIMESTAMP. Перед вызовом time() в перловом скрипте
SA>> была выборка из другой таблицы, кажется, дело в этом, она, видимо, тоже
SA>> блокировалась полностью, и этот запрос не проходил, ну, значит, надо
SA>> было time() в другом месте поставить.
MT> Может стоит использовать SQL'евские команды? NOW() например.
MT> К примеру у меня в таблицах поле со временем добавления записи
MT> default now(). Я даже это поле не заполняю -- на default и стоит.
Было бы то же самое, как мне кажется. А вот если б в перловом скрипте
оно было в самом начале, то он бы поспал до завершения VACUUM, а потом бы
вставилось как раз то значение, что надо.
MT>>> Мне MySQL не нравится, хотя API понравилось больше, нежели у
MT>>> PostgreSQL.
SA>> Из perl к ним API почти одинаковое, за исключением некоторых
SA>> особенностей, которые я предпочитаю не использовать, чтоб не иметь
SA>> проблем
MT> Я имел ввиду C'шное API.
Клиентское или серверное? Мне кажется, что городить с клиентской
стороны что-то на С для такого рода БД чревато потерей времени и глюками. С
серверной оно имеет смысл для расширения набора функций хотя бы.
SA>> есть "several clicks installer" под win32,
MT> Очень полезная штука. ;) Sybase вон инсталиться тоже просто -- rpm'ки
MT> назапускал, а потом сиди как дурак и raw девайсы плоди. Да и бэкапом у
MT> него одни проблемы -- он структуру не сохраняет. ;( Вообще у нас
MT> программист БД глянув на PostgreSQL сказал, что в нем (в PostgreSQL)
MT> есть много того, чего нет в Sybase. ;) Правда в PostgreSQL нет много
MT> того, чего нет в DB2 (или как там правильно пишется). ;)
От sybase на линуксе я только клиент ставил, работает как часы. Сначала
сконвертил alien'ом rpm, потом его поставил, потом прописал каталог с
библиотеками в ld.so.conf, и все заработало. А, ну еще написал
$SYBASE/interfaces.
SA>> для PostgreSQL я такого в то время не
SA>> видел, нужно было еще всякую дополнительную фигню отдельно лепить,
SA>> (UNIX sockets, кажется?) и без Cygwin оно не работало вовсе.
MT> Сейчас делают родной порт под Win32. Пока еще не готов. Есть нативный
MT> старый порт, но чисто японский -- японская локаль и т.п. Кривой
MT> какой-то. ;)
Hу вот. 2 года назад было то же самое.
SA>> Опять же, на любом хостинге, где дают CGI, почти наверняка есть
SA>> mysql 3.23.xx, и ничего другого.
MT> Сейчас уже много хостингов, где и PostgreSQL дают. ;)
Hе очень. Я осенью этот вопрос исследовал.
[ ...skipped... ]
SA>> того, чтобы обойтись .dbm - я просто не в курсе этого API, но мне
SA>> кажется, что там придётся конструировать вывод запроса вроде
SA>> SELECT f.ID, b.NAME FROM FOO AS f, BAR AS b WHERE b.ID=f.GOOD AND
SA>> f.ID>153,
MT> А MySQL такое проглотит? Я давно уже не смотрел чего там есть. Когда
MT> последний раз я им занимался там даже транзакций небыло. Из-за этого он
MT> и отпал сразу. Хотя первая причина была в том, что когда мне понадобился
MT> SQL сервер, то MySQL на тот момент хотел glibc2, а у меня еще была
MT> libc5. ;) PostgreSQL у меня встал, вот я к нему и проникся за столько
MT> времени... ;)
PostgreSQL я в том или ином виде щупал, начиная с 1999 года. Hо Sybase
5.5 был на тот момент лучше, а лицензирование вообще вспоминалось только
касательно поддержки.
--
Svyatoslav <absolute_sh@mail.ru>
[Registered Linux user #219421]
--- QDed/Linux
* Origin: AbSolute Soft&Hard (2:464/8088.100)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
