Коммерческое антиспамное решение, построенное на базе Linux и PostgreSQL, весьма шустренько работает с БД, содержащей правила и параметры для адресов почты (укладывается в 3-секундный тайм-аут).
простите, может это не мое дело, но всеже - ничего, что данная антиспамовая система стоит бабок а новость из раздела open source? и замете - свободно эту приблуду не скачаешь! или запрет на рекламу относится только к российским проектам - всяким асплинукс, альтлинукс и иже с ними????
>>простите, может это не мое дело, но всеже - ничего, что данная антиспамовая система стоит бабок а новость из раздела open source? и замете - свободно эту приблуду не скачаешь!
open source не обязан быть бесплатным. Купи его - и тебе дадут source.
чето я не нашел подобной инфы на http://antispam.datainfosys.net/ :\ а проблема в том, что порекламировав открытую разработку не меньшая реклама досталась и комерческой системе.... :(
К сожалению dspam с PostgreSQL очень сильно грузит систему.
На одной и той-же машине с MySQL в разы быстрее и меньше нагрузка.
Хотя я большой поклонник PostgreSQL, но для словопомоек преимущества
PostgreSQL ничего не дают :-(.
а во фрибздёвых портах и postgresql74 и postgresql8 помечены брокенами... блин. месяц назад postgresql7.4.6 ставилось и работало (до сих пор работает)...
Кстати, в доках (постгреса) написано, что постгрес быстрее работает с UFS, и типа, рекомендуется... как это понимать? учитывая, что ext3 с неполным журнилированием местами почти вдвое быстрее UFS2 с SU?! Как так можно умудриться затормозить быструю линуховую дисковую подсистему?! :-(
Действительно затрахала... Кто-нить знает систему, которая не борется со спамом, а просто четко определяет и давит оного. Ибо кол-во спама растет по экспоненциальному закону от кол-ва клиентов. Т.е. если клиентов больше 100 то уже 90% почты - это спам, на разгребание которого уходят часы рабочего времени (это при работающих spamassassin, bogofilter, rbl , ежедневным пополнением порядка 100-200 писем в базу и др. фильтрами).
> Блин а почему никто не сделает систему вырезания телерекламы из эфира? Затрахала уже эта тотальная борьба со спамом... От нее только одни проблемы.
есть такой кекс Конев. он делал. вернее нанял студентов, они сделали, потом разосрались и проект заглох. поишите whois r-master.ru
а задумка была не плохая. слушаются все программы и в реальном времени из них вырезается реклама. и записываются без мусора. в реальном времени вместо рекламы можно было смотреть другие программы. правда, как это выглядело на самом деле - не знаю :)
куча железа + куча софта.
распространялся этот сервис за деньги. но не выжил.
>>Блин а почему никто не сделает систему вырезания телерекламы из эфира? >>Затрахала уже эта тотальная борьба со спамом... От нее только одни >>проблемы.
>>vs240 * (*) (29.12.2004 19:58:06)
в Австралии это есть за дополнительные деньги ставишь вырезатель рекламы
он вроде переключает на другой канал или включает музыку когда обнаруживает рекламу
Новость похоже взята из ленты новостей Postgres (конкретно, отсюда: http://www.postgresql.org/about/news.264 ), а туда ее запостил один из разработчиков этой "супер-пупер" системы...
> Сейчас выбираю базу данных, которая как раз могла бы адекватно работать с большими объёмами данных
Если не нужны какие-то особые навороты, то лучше взять MySQL - в 99% меньше == быстрее, а размер таблицы в последнем ограничивается только максимальным размером файла.
> Если не нужны какие-то особые навороты, то лучше взять MySQL - в 99% меньше == быстрее, а размер таблицы в последнем ограничивается только максимальным размером файла.
И даже это не совсем правда, если в MySQL использовать тип таблицы InnoDB то она может хранить данные в разных файлах и "захватывает" дисковое простанство порциями а не при каждом INSERT, все почти как у взрослых
А навороты - это что? В смысле: объединение трёх таблиц считать наворотами?
С размером меня интересует скорость работы - на линейность, наверное, и расчитывать глупо, но хотелось хотя бы приемлимое падение производительности при увеличении объёма... То есть хорошую масштабируемость... =)
Потомучто если ставить Oracle в соответсвии с рекомендациями, то там на разные физические диски разносятся данные, индексы, временные файлы и т.п. причем это выглядит не как файл в файловой системы, а как специальный раздел жесткого, чтобы не было отрицательного влияния на производительность от таких эфектов как: дифрагментация, доступ к файлам другими приложениями.
какой такой "доступ к файлам другими приложениями"?! а файлы можно разнести и в постгресе на разные диски. а ещё UFS и EXTx не фрагментируются практически...
>какой такой "доступ к файлам другими приложениями"?! а файлы можно разнести и в постгресе на разные диски. а ещё UFS и EXTx не фрагментируются практически...
я же не говорю что этого нельзя сделать, просто допустим по default у тебя есть отдельный раздел /var У тебя в этом разделе помимо /var/lib/mysql/ или /var/lib/pgsql/ живет еще и /var/log/. Естественно если нужно добится максимальной производительности все делают на отдельных разделах или даже физических дисках.
знаешь, по-дефолту в таком весьма серьёзном дистрибе как SuSE один раздел, корневой. и рута по ssh пускает. и ещё подобная хрень... кого волнуют дефолты, когда разговор зашёл о серьёзном тюнинге?
Если хочется ускорить PostgreSQL и использовать его в задачах, где MySQL шустрит (т.н. линейные запросы), то используйте индексацию с методом hash, а не b-tree (см. синтаксис CREATE INDEX).
на машинах, где порт sshd открыт (фаерволой) на весь мир (ну, бывает, что надо!), разумнее запретить непосредственный логон рутом. а где разрешён только для 1-5 своих IP-ов, глупо не разрешать... а пользоваться sudo, зная пароль рута, - это извращение....
>а пользоваться sudo, зная пароль рута, - это извращение....
sudo позволяет исполнять комманды (какие настроишь) под правами суперползователья НЕ ЗНАЯ пароль рута. Хотя, ИМХО, это и так всем извесно... но мы отклонились от сабжа =) тема была замечательная СУБД постгрес ;)