> Ты знаеш скока потом делался простейший селект для выборки общего объема трафика для определенного IP?

Вот в такого рода задачах и рулит mysql. А если учесть еще системные требования мускула то никакой мастодонт в таких условиях не выживет. Для простой и тяжелой работы все эти дополнительные сиквел фичи только помеха, а необходимую функциональность и обработку можно обеспечить внешними прогами.

Да мускул хорош при селектах ... даже смею предположить что он лучший при селектах ... НО update и insert у него настолько тормознутый что лучше даже не вспоминать ... я ж грю для таких задач лучше подходит BerkeleyDB!

>>работы все эти дополнительные сиквел фичи только помеха, а необходимую функциональность и обработку можно обеспечить внешними прогами.

Можно.. а еще можно на бумаге делать..
Вопрос в "временой" стоимости написания аплликухи. Хотя как студенческий практикум по изобретению велосепеда пойдет, но в бизнесе время дороже денег и идеи. Для любителей устроить "закат солнца вручную" предлагаю "пописать" внешними средстваими аналитические оконные функции. Это так, первое что пришло в голову...



>>А если учесть еще системные требования мускула то никакой мастодонт в таких условиях не выживет

А если еше учесть, что большинство фришных субд в ТОДО, грубо говоря, стоит достичь возможностей оракла 7.3 (речь только об реляционом енжине, ибо достичь уровня продукта оракла нереально) то вопрос железа собсно соизмерим..

для подсчета трафика такая апликуха пишется за неделю ... но это только для подсчета ... т.к. биллинг в разы удобнее делать на SQL с триггерами и хранимыми процедурами ...

NiKel (*) (23.04.2004 13:37:34):

> Такая вот задачка например - в системе идут мегабайты логов, но чтобы не делать монструозные текстовые файлы перенаправляем все это в базу. ... Ну и что лучше мускула подойдет для этого?

На вот, покури: http://telegraph.cs.berkeley.edu/telegraphcq/v0.2/

пасиб за ссылку ... вот это прикольная весч ... а что если туда весь netflow загнать ... у меня в 5 мин ~100 тыс потоков ....

>>для подсчета трафика такая апликуха пишется за неделю

Я врядли открою секрет, если скажу что подсчет трафика примитивнейшая задача. По той причине, что там нет логики.. Тоесть "траффик" не может быть сгенерирован "задним числом". Его нельзя "закачать" обратно, если клиент понял, что он ему не нужен :) Ну или что-то в этом роде.. Тоесть задача проста, потому как алгоритм ее решения ясен и "прям" как дорога в пивной ларек.

Основное применение СУБД это комерция, и первое ее проявление - торговля. Большинство всех примеров по аналитическим отчетам показываються иммено на примере продаж. И вот на генерации всевозможных отчетов, сразу как то становеться "чувствоатся" что select,insert, update from simpletable и даже не их скорость есть показатель "рулезности" RDBMS. Почему то сразу хочеться открыть а96540.pdf и поискать на тему snapshot, rollup, lag, lead, connect by, groupping и т.д.

мне вообще очень SQLite понравился для домашнего использования и простеньких задач.

chl

Маленкие программулины - а на фиг им отдельный (пусть даже и порезанный) SQL сервер? Им SQlite за глаза хватит имхо.

Во наконец то толковый чел нашелся ... полностью согласнен ... а этот хренов мускул не туда не сюда получается ... я же грю для таких задач как подсчет трафика лучше в BDB все пихать ... а если нужна поддержка бизнес процессов то лучше в нормальную базу где ACID намально поддерживается.

это тоже к вопросу гимп вс фотожоп =) пусть о "хотя бы достигнет" волнуется тем кому оно надо. если человеку на надо все фенечки то юзать продукт с ними - излишняя трата. блин. ни ктож не опровергает роль оракла в корпоративных задачах, успокойтесь =)

chl

А чем BDB лучше то для хранения трафика чем mysql, какое у него преимущество????

тем что нет прослойки в видt SQL.

ifconfig

речь не о том что фичи оракла не нужны, а о том что они не нужны везде. mysql узкий и тонкий инструмент и полезно иметь представление где он подходит лучше всего, это постгресс ставит задачу получить нечто полнофунциональное за дешевую цену, мускул же, насколья я знаю - всегда ориентировался на предельную скорость для определенного круга задач, намеренно отказываясь от универсальности и фичастости, особенно если она вредит основной идеологии, предоставляя при этом удобный интерфейс для разрабочкика приложений расширяющих функциональность самого сервера, и такой подход оказался довольно успешным

r

> Текстовый файл

те же логи вполне можно писать в текстовый файл как это делается традиционно, но во первых - мы будем заносить туда много избыточного текста дабы структурировать информацию (можно конечно просто табами разносить поля - но тогда мы получим ту же таблицу в которой потом еще фиг кто разберется) и во вторых затем нам придется писать хитрые скрипты чтобы её проанализировать.. ну и зачем изобретать велосипед если уже три десятка лет как изобрели реляционные базы.. Просто раньше CУБД - это было нечто большое и страшное, теперь же несколько мегов в оперативке дают нам быстрый движек манипулирования данными с богатой функциональностью практически в любой системе, и какой смысл от этого отказываться?

NiKel (*) (23.04.2004 15:57:51):

> речь не о том что фичи оракла не нужны, а о том что они не нужны везде. mysql узкий и тонкий инструмент и полезно иметь представление где он подходит лучше всего, это постгресс ставит задачу получить нечто полнофунциональное за дешевую цену, мускул же, насколья я знаю - всегда ориентировался на предельную скорость для определенного круга задач, намеренно отказываясь от универсальности и фичастости, особенно если она вредит основной идеологии,

А теперь после всего этого п#@дежа, ответь: нахрена мысклеписатели лихорадочно добавляют сейчас все эти "ненужные" фичи в своё поделие? Они его помедленнее хотят сделать?

Или просто они тебе, глупому, лапшу на уши вешают и продолжают вешать?

>А чем BDB лучше то для хранения трафика чем mysql, какое у него >преимущество???? особенно это забавно тем, что помимо innodb в Mysql базы как раз bdb :))

>Ну смотри если идут данные по трафику (например нетфлоу) то пихать это все в SQL полное изврат. Я пробовал как то так делать ... и что ты думаеш за 1 час у меня набежало ~500 тыс строк. Ты знаеш скока потом делался простейший селект для выборки общего объема трафика для определенного IP? Поэтому такие данные лучше хранить в BerkeleyDB

Неа. Не надо в Berkley. И тем более не надо в SQL. У меня за сутки _десятки миллионов_ записей, а простые выборки занимают десятые доли секунды. Для этой задачи другой подход нужен :)

>>речь не о том что фичи оракла не нужны, а о том что они не нужны везде.

Речь о том, что появляються подобные статейки и с завидной регулярностью треды на эту тему.

>А теперь после всего этого п#@дежа, ответь: нахрена мысклеписатели >лихорадочно добавляют сейчас все эти "ненужные" фичи в своё поделие? >Они его помедленнее хотят сделать? > >Или просто они тебе, глупому, лапшу на уши вешают и продолжают вешать?

Придурок ты. Фичи добавляются так чтоб они не мешают основной идеалогии - скорость. Хорошая быстрая БД, для простых задач, что составляет 75 % всех задач, далее Посгрес и Оракл.

И какой если не секрет ?? DbVista CodeBase. Или свой алгоритм обработки логов ?

ifconfig

> Речь о том, что появляються подобные статейки и с завидной регулярностью треды на эту тему.

Ну да вообще то, дело ведь не в самой статейке а в теме с её "VS" , то есть изначально флеймовой :) Ну что же, они хотели флейма - они его получили :)

И главное что всегда найдется отморозок типа sad_spirit которому непременно надо будет перейти на личности, для убедительности или от общей ущербности - хрен его знает..

vtVitus (*) (23.04.2004 17:11:22):

> Придурок ты. Фичи добавляются так чтоб они не мешают основной идеалогии - скорость.

А, то есть во всех остальных СУБД фичи мешают скорости, а вот мыскль волшебный --- в ём не мешают? :]

NiKel (*) (23.04.2004 18:00:19):

> ты убог и глуп - пошел на хуй

то есть на вопрос по существу ответить не можешь, можешь только обиженно сопеть? что и требовалось доказать...

anonymous (*) (23.04.2004 18:04:56):

Сорри, это опять был я.

Мл... ну сколько можно говорить? Юзайте sqlite и живите спокойно...

int19h

sqlite - это дело :) но ведь опять кто то будет морщится от его несовершенства

вообще imho мускулу ораклы и даже постгресы не конкуренты, а вот sqlite - конкурент, с другой стороны если и на первом пне mysql живет неплохо, то на P4 выявить разницу между ним и sqlite будет сложно, вот тут и пригодятся новые фичи мускула который все знают и который везде работает уже не один год..

> А, то есть во всех остальных СУБД фичи мешают скорости, а вот мыскль > волшебный --- в ём не мешают? :]

Именно поэтому их и не вводили сразу.

Если сделают вложенные селекты, то полагаешь обычные станут от этого медленне? Вряд ли.

четвертая версия мне, например, показалась чуть медленнее чем треья, но на единицы процентов, а не в разы. Но я и не пытался это оптимизировать - не за что там было бороться. И потом все равно эnи фичи если и введут, то они будут под кнтролем configure. Не хочешь - не ешь.

Этот спор перекликается с множеством других споров на LOR-е. Один говорит : ------------------------------------------------------------ реплика : KDE - rulezz ! полнофункционально, все умеет делать. ответ : KDE - тормоз ! KDE - не нужен. FluxBox - Rulezz ! ответ на ответ : работай в консоле, зачем тебе гуй ?? ------------------------------------------------------------ реплика JAVA - rulezz ! кроссплатформенно, множество средств облегчающих разработку. ответ : жаба тормоззз ! жаба не нужна, Си рулит. ответ на реплику : 1. работай на ассемблере. 2. пиши в машинных кодах.

Этот список можно продолжить :))

Вопрос, кто же прав ?? Ответ,- никто. Догадаетесь, почему ?? :)

Игорь.

> Неа. Не надо в Berkley. И тем более не надо в SQL. У меня за сутки > _десятки миллионов_ записей, а простые выборки занимают десятые доли > секунды. Для этой задачи другой подход нужен :)

А выборка делается за несколько лет, да? :-) Прям заинтриговал :-) Похвастайся, мне, например, интересна...

>>Этот спор перекликается

Это оне спор, это запланированый флейм.
Просто забано смотреть на эволюцию..
За последние 4 года здесь в тредах про базы данных сменилось три-четыре группы тваришей.. Все говорят приблизно одно и то же :)

> sqlite - это дело :) но ведь опять кто то будет морщится от его несовершенства

Как конкурента MySQL? На всех предложенных выше для мускуля задачах, sqlite предлагает те же (а то и большие: триггеры etc) возможности при меньшем потреблении ресурсов.

> вообще imho мускулу ораклы и даже постгресы не конкуренты, а вот sqlite - конкурент, с другой стороны если и на первом пне mysql живет неплохо, то на P4 выявить разницу между ним и sqlite будет сложно,

А что, sqlite плохо живет на первом пне? Нет, правда, интересно =)

> вот тут и пригодятся новые фичи мускула который все знают и который везде работает уже не один год..

А какие у мускуля фичи (кроме типизации) которых для вышеописанных задач не хватает в sqlite?

int19h

насчет пня ты не понял логику :) Поясняю. Если на первом пне mysql не тормозит то на 4м - летает, и если еще кто то там рядом летает в полтора-два раза быстрее то это уже может быть вообще несущественно..

что касаемо фич - mysql все-таки DB посерьезнее будет, imho.. хотя с лайтом не разбирался - вообще к нему можно приконектится по сети? как там обстоит дело с правами пользователей и грантами? Или это только движек, библиотека сохнанения/манипулирования sql данными в юзер программах плюс утиль запускаемая чтобы добавить/извлечь нетипизированные данные из одного большого файла? Насколько я понял sqlite не работает в виде процесса как сервер который обслуживает запросы клиентов, он сам себе и клиент и сервер для работы с файлом базы , ну и всяко плюс движек и библиотека для встраивания во всевозможные программы и скрипты..

> что касаемо фич - mysql все-таки DB посерьезнее будет, imho.. хотя с лайтом не разбирался - вообще к нему можно приконектится по сети?

Можно, через файл-сервер - вроде бы там блокировка на уровне записей. Хотя конечно в таком режиме по производительности ему до мускуля далеко. Но вот скажи, для тех задач, которые тут были перечислены - логи там вести, небольшие базы данных, специфичные для данной проги - удаленный сервер не нужен совершенно. Так же как и для многих мелких сайтов на PHP. Тогда зачем весь этот огород городить?

> как там обстоит дело с правами пользователей и грантами?

Никак. База - файл на диске. Какие права на файл поставишь, такие и будет.

> Или это только движек, библиотека сохнанения/манипулирования sql данными в юзер программах плюс утиль запускаемая чтобы добавить/извлечь нетипизированные данные из одного большого файла?

Ну, типа того. Вроде как ADO.NET, работающая с MDB-базой. Только тут SQL нормальный, и скорость повыше =)

> Насколько я понял sqlite не работает в виде процесса как сервер который обслуживает запросы клиентов, он сам себе и клиент и сервер для работы с файлом базы , ну и всяко плюс движек и библиотека для встраивания во всевозможные программы и скрипты..

Совершенно верно. То есть - тулза, подстроенная под определенный круг задач. Как пример того, как его можно использовать: iTunes-like плеер Musik хранит базу именно в sqlite, таким образом, это один файл, который юзер может спокойно копировать с системы на систему, с другой, поиск по базе элементарно реализуется средствами SQL, причем с весьма неплохой скоростью.

даа. блин.
весь этот флейм мне напоминает спор о машинах.
некоторые и жигули называют словом "машина". говорят что на ней тоже можно ездить, но молча завидуют тем кто катается на меринах....
а то хули? нафига нам АБС и подушки безопасности? я ведь в аварии не попадаю.

int19h

да хорошая тулза, часто именно такую и нужно, только вот сети разные и интернеты разбаловали - хочу типа чтобы моя прога шла на одном компе а читала базу с другого или 5 узлов писали логи на один общий а не каждый у себя и тд.. то есть задачи те же в общем то - нехитрый сброс данных но в сетевой среде.. можно конечно расшарить файл с базой, прописать права к нему и пользоваться с другого компа, но тогда возникают вопросы по поводу совместного доступа или как свести данные вместе.. для многих задач быть может это и не требуется но после практики работы с другим сервером баз данных этого уже может недоставать, ведь в общем то достаточно 3-4 строк чтобы описать удаленное соединение и после его создания пользоваться что локальной, что удаленной базой совершенно одинаково, не задумываясь о физическом размещении файлов

> Вот в смешного шрама складочках и ссорит mysql. А если сплестись еще системные требования чудака то стручковый мастодонт в нагих внушениях не выживет. Для простой и тяжелой фугетты все эти неуживчивые сиквел фичи только чернушка, а самопрялочную функциональность и серенаду можно обеспечить павшими прогами.

А вдруг выживет?

> кость не о том что фичи оракла не лестны, а о том что они не спорны везде. mysql узкий и круглый готтентот и полезно вшивать расширение где он подходит лучше всего, это постгресс блудит фасетку заскулить нечто полнофунциональное за дешевую курву, факел же, насколья я смею - всегда диагностировался на пожолклую нетель для определенного круга раззяв, намеренно стушёвываясь от осязательности и фичастости, особенно если она столбит синивший спецификации, подготовляя при этом удобный интерфейс для разрабочкика приложений расширяющих несовершенность самого заброса, и такой подход оказался скаредно канвовым

А за раззяв ответишь!

> те же лики вполне можно писать в цензорский файл как это согреется несущественно, но во хмельных - мы сбудем мастерить туда много беспечального текста дабы структурировать нейропатию (можно печально рябо табами разносить поля - но тогда мы выманим ту же таблицу в премилой потом еще грыж кто разберется) и во грядных затем нам придется писать косные скрипты чтобы еЈ перередактировать.. ну и зачем обалдевать нефтезавод если уже три десятка лет как переплели реляционные базы.. Босо раньше CУБД - это встряло нечто другое и шейное, теперь же несколько мегов в сковородочке дают нам быстрый движек самоцитирования вбитыми с богатой периодичностью пророчески в любой женщине, и какой вол от этого обвешиваться?

Ну да, если таблицу выманивать, о можно и обвешаться.

lol

В кои-то веки и от анонимусов какая-то польза =)

>> Если на первом пне mysql не тормозит то на 4м - летает,

Это извините, как понять.. Что собсно летает??

И еще, Вы когда нибудь в производительность "упирались" ?? Ну там запросы которые часами исполняються... Если нет, тогда "летает" это беспредметный спор.. Хотя select 2*2 from dual будет "летать" безусловно на любом железе :))

ifconfig

Да можно никак не понимать :) Ты вот жив или мертв? Насколько собственно жив? И вообще ты ли это? Можно было бы вообще ничего не говорить.. Запросы часами понимаешь.. а процесс приема пищи 1 или 100 минут. А некоторые вообще голодают. Ну и что? Иногда между быстро и очень быстро разница непринципиальная чтобы ради неё что то менять. Там где разница уже чувствуется и принимаются соответсвенно решения, а просто ради принципа и бенчмарков делать апгрейды или менять софт я бы не стал. И вообще какой смысл разьяснять подобные вещи? На любое утверждение, даже самое тривиальное всегда найдется желающий указать на какое то свое особое исключение. Снег белый - да вот иногда и не белый.. бла бла бла. Трава зеленая - да вот не видели вы красной или желтой травы .. бла бла бла и тд и тп. Иногда в этом некоторые и видят смысл спора.

А кто то вообще путает теплое с мягким. Типа девелоперы mysql приняли обет аскезы во имя идола бенча. Ну а коль нарушили обет и создали фичу новую - значит виновны, проявили подлую натуру и значит всех обманывают и тайно мечтают стать ораклом. И скажи такому больному что никакого обета нет и фичи появляются в ходе нормального процесса развития - он вообще не поймет о чем речь и назовет всех глупыими ибо ничего другого ему в бошку не придет..

8====D

>> поскипано..

Все написаное хорошо, но ни о чем :)

и причем тута бенчи?? я спрашивал насчет того, "упирались" ли в реальных прикладухах в производительность??
Просто я зачастую сталкиваюсь с тем, что народ вообще слабо себе представляет что такое реальные базы с сотнями клиентов и что такое "тормозит".

просто читать интересно мнения серьезных программистов :) мускул зачастую не справляется с задачами вебмастеров, а особенно адалт веб мастеров которые обмениваются траффом в десятки К в день, просто зачастую для разных задач разные решения, разве это не прекрасно :). оракл вообще для веб задач отдельных личностей не подходит по причине того что его начинаещему ставить и разбиратс яэто год уйдет. и удалеено на дедик не поствишь, или что то изменилось за последние 3-4 года :) да, и еще эти самые мастера или отдельные их представители зарабатывают до нескольких десятков К президентов, разве это не прекрасно, а вы все спорите, пора работать Ж)

>>PHP - такого бардачного языка я в жизни не видел, бэйсик отдыхает.
Ну бардак кой-какой действительно есть :) Однако писать на нем на порядок проще чем на perl :) Проще и наглядней.
И уж явно будет по круче васика все таки классы есть, регекспы и ассоциативные массивы, да и предназначен для другого.
Короче говоря имеет право на существование :)

Хватит гнать на mysql - для своих целей отличная база.

А может кто-нибудь привести сравнение MySQL и PostgreSQL ?
MySQL я знаю и пользую, хотелось бы узнать стоит пробывать PostgreSQL ?
Что в нем есть хорошего/плохого ? Хотелось бы объективного обзора желательно на русском.

>>Зато он BSD, а не GPL.
Это-то как раз минус тормозящий развитие.

>>ибо достичь уровня продукта оракла нереально
Точняк ! Даже сам оракел себя не достиг !

> MySQL я знаю и пользую, хотелось бы узнать стоит пробывать PostgreSQL ?

Стоит.

> Что в нем есть хорошего/плохого

А ты почитай доки. Думаю, быстро разберешся, что в нем хорошего =)

http://www.postgresql.org/docs/7.4/interactive/index.html

Это почему это не поставишь?
Замечательно ставицца на "дедик"

Про http://sqlite.org/: подскажите как там сделать desc имя_таблицы ?