Создание своей СУБД + вебсервера + системы автоматизации

>[посыпает голову пеплом] вот так пишешь-пишешь говноскрипты на перле.
считая большой удачей то, что при очередном нагрузочном тестировании говносервер выдержал 1500 запросов с секунду(не статика)

1500 запросов в секунду - с каким временем реакции? Грубо говоря, сколько запросов в час может обслужить? И какое железо? приблизительно? Я сейчас как раз занимаюсь вопросами производительности, но не могу найти конкретных цифр/примеров с чем сравнить. Например 500 пользователей с временем отклика не более 5 секунд в течении суток и без ошибок - это много или мало?

Нашел вот тут http://habrahabr.ru/blogs/hi/77593/ некоторые цифры.

хочется чем-то помочь благому делу. но скилов под эту задачу явно не хватает. (с функциональным программированием сталкиваться не доводилось)
однако, если потребуется помощь по части инфраструктуры/системного администрирования, буду рад помочь.
egor@agava.com

>1500 запросов в секунду - с каким временем реакции? Грубо говоря, сколько запросов в час может обслужить?

тестирование проводил написанным на левой коленке перловым скриптом.
800 форков, каждый из которых дергал определенные запросы каждые три + rand(3) сек. с пяти машин. (по ходу тестирования пару из них случайно положил (-; перл прожорливая до памяти штука..)
запросы делались тупо через Net::Telnet. Timeout => 5.

но тут задача была сильно специфическая. данные уже были предварительно заготовлены в memcached.

машина самая заурядная:
cat /var/run/dmesg.boot | grep 'real memory'
real memory = 2138832896 (2039 MB)

cat /var/run/dmesg.boot | grep CPU | head -1
CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2794.84-MHz 686-class CPU)

uname -srm
FreeBSD 7.2-RELEASE-p3 i386 ; )

2JFreeM

если же тебе запросы к СУБД надо дергать тяжелые, то юзать nginx + его perl для этого не стоит.
собсно, Сысоев у себя в документации это даже специально подчеркнул.

иначе ты в итоге изобретаешь apache13+mod_perl ; )

опять велосипед будешь соэдавать?

мне надо провести имитацию 1600 пользователей на форуме грубо говоря. С учетом загрузки статики, картинок, etc (для IPB на серверах инновы это был предел, увы, не знаю их железа). С некоторым элементом случайности. Т.е. запросы могут быть любые. Правда, пишу я на яве, но мне вот глобально интересен вопрос производительности маломощных систем. Я читал про архитектуры жж и еще некоторых больших сервисов и комментарии к этому всему реят из 37signals, которые говорят, что оптимизацией они добились гораздо бОльшей экономии, чем горизонтальным масштабированием. А поскольку я ограничен в средствах, кластера могу себе позволить только on demand (типа того же амазона) и сейчас высчитываю некоторую точку, в которой дальнейшая отпимизация нерентабельна. Может ли кто-то подкинуть литературы на эту тематику?

>Назови мне хоть одну работающую СУБД кроме оракла, постгреса и ms sql server? так что их не так уж и много.
Firebird

в этом итт-треде изобретают google bigtable. «изобретать субд - это весело» (ц)

> в этом итт-треде изобретают google bigtable

В общем, да. Но у тебя к варвару что-то личное, походу.

ты проницателен... Как догадался?

а сама СУБД отдельно, без автоматизации будет?

Не знаю, я тут вижу свой фан в формате сделать key-value storage с snapshots :) О большем я не думаю, пускай думают другие.

> - СУБД скорее всего (99%) будет писаться на эрланге (я уже начал писать некоторые модули)

безумие :-)

- я много пишу под оракл так что знаю что такое СУБД

подкину дров - уже решили какой диалект SQL будете поддерживать? ораклизмы или стандарт SQL?

- основными плюшками СУБД, в том числе, из коробки, будут кластеризация, (а)синхронная репликация, высокий уровень параллелизма.

Устойчивое впечатление что не с того конца начато. Что от этой СУБД будет требоваться-то?

Какие запросы будут? веб-подобная загрузка, где все 99% запросов имеют вид «select * from table where primary_key=?», или крутая аналитика c 20-табличными джойнами?

Будут ли важны конкурирующие транзакции и каких они будут размеров? В пару select'ов с update'ом или же кому-то придет в голову держать сутки repeatable read на половину базы в то время как ее другие раз в секунду пытаются обновлять?

могу и дальше продолжить.

Думаю надо сначала со всеми такими вопросами проясниться, и тогда уже станет ясно, кластеризация нужна, репликация, или что-то еще.

Еще приоритеты у желаемых фич надо очень четко расставить, иначе члены прожэкта потеряют к нему интерес до того, как агрегат сможет выполнить «select * from table».

Ага, загляденье. Если понимать, например, что разнести ее по кластерам нельзя.

В сущности тут есть сто тыщ разных проблем, балансируя между которами можно перегнуть систему в одну из сторон. Т.е. где-то ты будешь сосать, а где-то будет конфетка.

вот я готов повторить свои слова и тут, что мне как-то не в фан писать всякие sql. Простое хранилище с напшотами, да, там я могу найти себе фан. Выше, не уверен ;)

> > вменяемая документация планируется?

планируется более чем вменяемая. уж лучше чем у постгреса или mysql.

ой не зарекайся. Вменяемая документация у ms, cisco, sun. И там ее пишут шпециальные люди за спешиальные деньги.

> не очень, пока не вижу планируемых преимуществ перед существующим ПО. Ой, преимущества. Хм. А как же фан?

У меня вот так сложилось что вообще почти все сугубо самопал. И dns самопал, и mta за exim самопал, и вообще, я крайне странный тип который любит строить свои квадратные колеса (:

Ага, забыл про мнезию рассказать.

У мнезии есть эн проблем. Первая, у нее есть разные backend и надо понимать что у dets есть лимит на размер таблицы.

Далее у нее нет понятия реплекация, вместо нее идет распредлеенная транзакция, т.е. если какая-то нода отстала, начинается ой. Вот именно этот момент многим мешает. (Собственно благодаря распредлеенной транзакции и может быть master-master репликация).

Ой, а куда тупее-то чем в мнезии? тупее чем dets/ets уже некуда. (:

Именно это во всей этой вакханалии меня и напрягает. Нет что бы сразу к разврату приступить, так нет, мы понять не можем, хотим ли мы осликов или енотиков (: (/me давно понял чего он хочет и не против сделать, ага ;) )

У людей трава хорошая и дури много. А еще люди гамбургеров объелись.

А 1500 тысячи запросов, на статике... А что за статика, кстати, какой размер? Какой канал? Какой сервер? :)

p.s. — самый правильный способ борьбы с highload это добивать железа!

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

ага, google bigtable. Ага, изобретаем. Их уже столько изобрели, что обизобретаешься. :)

>> - я много пишу под оракл так что знаю что такое СУБД

подкину дров - уже решили какой диалект SQL будете поддерживать? ораклизмы или стандарт SQL?

Скорее всего ора-клизмы.

- основными плюшками СУБД, в том числе, из коробки, будут кластеризация, (а)синхронная репликация, высокий уровень параллелизма.

Устойчивое впечатление что не с того конца начато. Что от этой СУБД будет требоваться-то?

Какие запросы будут? веб-подобная загрузка, где все 99% запросов имеют вид «select * from table where primary_key=?», или крутая аналитика c 20-табличными джойнами?

по моему опыту, веб-подобная нагрузка происходит от неумения работать с СУБД и от неспособности СУБД рабортать корректно. У меня были сайты на оракле где весь сайт собирался с помощью одного селекта, даже если на главной странице была куча лент новостей и тд - просто селектом выстраивался огромный XML (оракл умеет с ним работать) и потом отдавался в XSLT.

Будут ли важны конкурирующие транзакции и каких они будут размеров? В пару select'ов с update'ом или же кому-то придет в голову держать сутки repeatable read на половину базы в то время как ее другие раз в секунду пытаются обновлять?

Будут, будут. Я же говорю - я ораклист. Так что будет всё что относится к ораклу. Но при этом в веб-исполнении.

Еще приоритеты у желаемых фич надо очень четко расставить, иначе члены прожэкта потеряют к нему интерес до того, как агрегат сможет выполнить «select * from table».

Угу вот тут есть вопросы ))))))))

> Нет что бы сразу к разврату приступить
Кир, нет проблем. Я могу тебе асболютно точно озвучить требуемый интерфейс к хранилищу. И приступай к разврату прям щас.

> Хотелось бы услышать мнения сообщества ПО ДЕЛУ.

Взять _готовую_ СУБД и не заниматься всяким \ldots Изучите внимательно возможности PostgreSQL - там всё есть. Доработайте её под задачу (там очень хороший и отзывчивый коллектив разработчиков) и будет всем счастье.

P.S. Если же не вняли голосу разума, то не рассчитывайте на вменяемый результат раньше десяти лет активной разработки.

> Назови мне хоть одну работающую СУБД кроме оракла, постгреса и ms sql server?

Что значит работающая? Firebird работающая? Objectivity работающая?

Субд нового времени уже есть - это Couchdb. приделайте к ней нормальные транзакции и map/reduce chaining - больше ничего не нужно.

>Например, была идея ОО-базы данных, но на момент когда я или кир пытаемся представить себе наследование, у нас мозги закипают.

Наследование легко реализуется средствами РСУБД, на уровне таблиц и ключевых полей, это не проблема.

Цитируем catap

простой key-value storage

couchdb?

А зачем свой веб-сервер писать я не понял? (inets|yaws|mochiweb) + nitrogen - и навороченный вебсервер с крутейшим фреймворком готов.

>Назови мне хоть одну работающую СУБД кроме оракла, постгреса и ms sql server? так что их не так уж и много.
MaxDB

Платформу разработать весело, особенно вспоминая историю компании SAP AG и какого овер 9000 профита они получили. Только разве проблема в платформе? насколько я понимаю основная проблема в менеджменте и в том как они пытаются управлять... как можно автоматизировать то, что и сами менеджеры не понимают как работает, кто понимает те, небось, давно автоматизировались

нужно сделать под ключ с включёнными бизнес-процессами(или любым другим способом управления), чтобы даже тот менеджер, что прогулял все лекции(большая часть) не смог ничего испортить и при этом был как бы нужен. Сделать несколько готовых 'ларёк', 'сервис-центр', 'склад', 'перевозки', что там ещё в России есть такого а ну да учёт типа 'бухгалтерия' и тогда уже можно бежать рубить капусту.

как-то так думается мне.

> чтобы даже тот менеджер, что прогулял все лекции(большая часть) не смог ничего испортить и при этом был как бы нужен

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

Гм? Это не обычная key-value database которая не умеет шардинг. Каким боком это Субд???

Да? А можно мне объяснить как наследование происходит, а? А то я сколько пытаюсь, не могу.

Я готов с вами даже бургер скушать, под это дело-то!

> Корованы, корованы забыл!

Вроде уже выпустили игрушку с караванами. Так что поздно.

Всё просто:
(упрощённо)
три таблицы
1-я - дерево классов(class_id, class_name, parent_id)
2-я - их свойства(class_id, prop_id, prop_name)
3-я - значения свойств(class_id, prop_id, value)
идея в том, что-бы потомки автоматом наследовали prop_id родителей, к примеру, через хранимую процедуру.
Знаю, косяк! value - не имеет типа. Можно ввести во 2-ю табл. поле type и 3-ю таблицу расширить на кол-во доменов или оставить его текстовым, что не есть хорошо для размера и скорости индексов. Кароче надо ещё думать.
Теперь полевой пример для простоты понимания
класс: Человек
свойства: Пол, ДатаРождения.
класс: Сотрудник - наследник Человека
свойства: Должность, ДатаПринятияНаРаботу, Оклад ...
финальный_класс: Вася_Пупкин получает в наследство все свойства родителей: Пол, ДатаРождения, Должность, ДатаПринятияНаРаботу, Оклад ..., но! Инициализировать можно не все, а только те, что нужны, а для неинициализированных свойств можно создать view и периодически напоминать об пустых полях и заполнять из по мере необходимости. Кстати финальный_класс может иметь свои уникальные нестандартные свойства, например, ЛюбимаяФутбольнаяКомманда :) Такое никакому C++ не снилось.

Я, надеюсь, вы не отрицаете, что это хуйня а не решение, а?