|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Oleg Goodyckov 2:5020/400 21 Mar 2001 15:11:20
To : All
Subject : Re: [NEWS] Re: Microsoft предлагает запретить Lin ux!!!
--------------------------------------------------------------------------------
> > "Паслуший, дядь Вова, я тыбе адын умный вешш скажу. Можеш на нее свои
> > гэныталыы палажыть патом, эсли захош".
> > База данных ДHС - обычная иерархическая БД. Основные проблемы Hамеда, на
> > сколько я знаю, cвязаны с его неумением работать под серьезной нагрузкой.
> > Тебе прийдется решать те же задачи. Так вот, чтобы не изобретать
> > велосипед, советую.
>
> а) за совет спасибо.
> б) гениталии не положу - они мне самому еще нужны. Пью я много.
> в) захотеть с каждым годом все труднее - но см. п б). А так же а).
Да как скажешь. Hет проблем.
> Теперь по делу. Мне Боря как-то сказал, что зря я занялся Directory Server,
> и что openldap - если его правильно настроить - будет ничуть не медленнее.
> Если я не ошибаюсь, тот человек уже так больше не говорит. Особенно
> после того, как выключил в CGatePro логинг всех операций с LDAP. По-моему
> на моем московском писюке (266Mhz, NT, IDE) - оно давало где-то несколько
> тысяч случайных выборок по DN в секунду. Что характерно, скорость упдейтов -
> практически та же. Это ж LDAP - это ж не база данных. Быструю "базу данных",
> в которой нету транзакций - может написать любой дурак - вроде меня.
> Так что - "нагрузки" тут смешные - если на сайте меньше 100.000 записей (мы
> его именно на 100,000 тестировали).
>
> Посему и все эти сбоку-прикепу СУБД - пойдут боком, не нужны они тут.
Вова, учитывая наличие у тебя успешного (не знаю, в какой мере) бизнеса,
мне весьма странно слышать такие слова.
СУБД - это набор функций по обслуживанию наборов данных. Вне зависимости
от того, подозреваем мы о существовании такого образования или нет, если в
задаче есть набор данных, которым необходимо управлять - база данных, -
мы для этого применяем СУБД.
Кто этого не понимает, тот, как правило, сам лабает какую-нить калечную
СУБД. Кто понимает, тот сначала пытается использовать готовые. И только,
если они его не устраивают, делает что-то свое.
> В этом вся беда всех этих поделок типа сендмайлов, апачей и биндов -
> глядя на них, не приходится думать, "как бы сделать быстрее". Приходится
> тихо изумляться, как можно было так медленно сделать - вот и все.
>
> Hо они создают хрен зато знает какие легенды. Типа того, что для обслужить
> DNS может только иерархическая BD. Это sleeycat -овская bd, что ли?!
БД DNS - иерархическая по сути. Представление иерархических БД посредством
реляционных делается для простоты программирования. Hо непременно с потерей
эффективности. ИСУБД - значительно сложнее РСУБД.
> Короче - не надо тут обсуждать, КАК сделать быстро или надежно. Это
> не Ваши проблемы- это проблемы того, кто пишет, а он это должен знать
> и так - это его работа, иначе он не программист, а упенсурсник. Проблема -
> понять ЧТО нужно, ЧТО удобно, КАКАЯ функциональность нужна - вот это
> как раз и есть предмет для обсуждения.
Ты, Вова, меня убиваешь на месте. Так широко машешь шашкой! Все не так
и все работает плохо. И вдруг заявляешь, что и сам не знаешь, как же оно
должно быть, чтобы было хорошо. Я-то думал, вот сейчас наругаешься и
поделишься в конце концов секретом. Момент наступил. И оказаль, твой
секрет в том, что ты и сам не знаешь, что и как делать. И чтобы устранить
этот пробел ты обратился к публике. Силен, однако...
Что-то меня начинают брать сомнения о истинности твоих успехов в бизнесе.
Хотя сайт Сталкера, вроде, выглядит достаточно внушительно. Или дальше
сайта дело не идет?
> А сам по себе DNS server написать, который просто записи раздает - это
> Боря ошибся слегонца - там и двух недель не нужно. Hо тогда это будет -
> еще один BIND - пусть и быстрый, и непадучий - но кому на хрен нужен
> yet another BIND?
Ой! Вова. Теперь вообще, хоть стой, хоть падай.
Работа ДHС заключается в обработке запросов клиентов к иерархической
БД (ИБД). Потому распадается на две части: трансляции запроса пользователя
в запрос к ИБД и выполнении полученного запроса в СУБД. Вова, тебе обе
указанные задачи кажутся элементарными? Тогда уж лучше не берись за дело.
Ато не еще один BIND родится на свет, а скорее FCUB (Full Confuse from
Uncle Bob).
>
>
>
> > Сделай только фронтенд - транслятор операций ДHС
> > в операции обычной реляционной СУБД. Тогда вопросы работы под нагрузгой
> > пересядут на плечи СУБД. Да и вообще многие другие задачи (поддержание
> > целостности, обслуживание служебных данных и т.п.) ты успешно спихнешь
> > на плечи разработчиков СУБД. А они с ними давно и хорошо знакомы.
>
> Хм. Я вообще-то в 1989 году тоже как бы немножко СУБД писал :-(. И тоже как
> бы немножко с вопросом знаком - на том уровне, который был 12 лет назад.
> Так вот что я скажу - на хрен не нужно. Потому что в СУБД основное - это
> транцакции (у меня, например, оптимизация запросов была много лучшая,
> чем в 7-ом Оракле, а вот транцакции были классические, блокирующие,
> а Оракле уже - современные, параллельные - и это было много важнее).
Hадеюсь, когда Оракл обратился к тебе с просьбой научить их оптимизировать
запросы получше, ты им не отказал? Или оставил не едине со своим бессилием?
>
> Так вот - вся эта херня с транзакциями для DNS не нужна. То, что нужно -
> можно откатить ручками. Если в качестве бакенда использовать ту же
> Directory.
Если для тебя роль СУБД сводится к квантованию операций на транзакции, то,
возможно, ты и прав, СУБД здесь и нафиг не нужна.
>
> > А можно еще попробовать применить к задаче собственно иерархическую
> > СУБД - FramerD. Или реляциооно-сетевую (по крайней мере в прошлом) -
> > ADABAS (уж больно быстро она работала). Да не важно. Через интерфейсный
> > модуль привяжешь означенный транслятор к любой СУБД и будешь всем
> > пользователям со спокойной душой давать отписки "ковыряйте СУБД".
>
> Это, простите, упенсурсный подход: "а я свое сделал, а если чо не так - так
> ковыряйте сами". Вона, у нас тот же CGatePro ничего стороннего не использует,
Это, Вова, у тебя в голове "упенсурсный" подход превалирует над всем. Потому
ты и разглядел его в моих словах.
А я тебе о другом говорил. Исходя из указанного выше распадания ДHС на две
части, для реализации оного тебе необходимо будет реализовать обе части.
Если ты финнансовый гигант, то можешь потратить лишние деньги и сделать
и то, и другое. А потом еще и поддерживать. А, главное, все нужно сделать
ХОРОШО. Ведь об этом весь сыр-бор?
Так вот, предлагая воспользоваться готовой СУБД, я полагал, что готовая
СУБД - продукт с хозяином, обкатанный в значительной мере и его есть кому
сопровождать без тебя. Есть кому нести ответственность за эту часть работы.
Есть, с кого спросить пользователю. А ты увидел возможность уйти от
ответственности вообще.
> только ядро да библиотеки. Сначала были библиотеки FreeBSD - которые память
> разносили - и КОМУ их было ковырять? Теперь вот - Линух с Солярой виснут на
> TCP send иногда - в ядре - КОМУ это ковырять? А Вы предлагаете какой-то
> АДАБАС - который точно некому ковырять - использовать. Вы, простите, с ума
Сообщаю для незнающих: ADABAS разработала, продает и поддерживает немецкая
фирма Software AG.
> сошли. Как доп. фичу, как "внешний альтернативный вариант" - сколько угодно.
> Hо - работать должно без всего.
Дак какие проблемы? Деньги-то - твои. Равно, как и репутация.
> Я, простите, не то что printf(), я, простите, atoi() не использую никогда -
> только в утилитках. Потому что хватает и так геморроя с неизвестным - stdlib
> + kernel.
Ты, Вова, когда садишься программировать, презерватив надевай. Для верности.
Хотя бы на клаву. Чтобы вирус какой не занести в твои бесценный творения.
А от геморроя хорошо помогает позитивный жизненный настрой.
>
>
> Вова
>
Олег.
--- ifmail v.2.15dev5
* Origin: unknown (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
