Разработчики MySQL начали работу над ее форком - Drizzle

> как-как, в ORM придется обратиться к объекту фильм, для него найти соответствующие объекты "файл", посчитать их количество и размер

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

> ORM - это Object-Relational Model или кто-то думает иначе?

я думаю иначе. Марш в гугл смотреть расшифровку буквы M.

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

Не вопрос - шикарно.

>А те компонетны которые хотят выкинуть (вьхи, тригеры и процедуры) не такие уж и бесполезные.

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

Глупости глупостями, а мелкие быдлоподелия компании Atlassian достаточно активно для выборок используют не реляционки, а индексы Lucene. Если вдруг интересно - http://blogs.atlassian.com/rebelutionary/downloads/tssjs2007-lucene-generic-d... - тут подробности почему так.

Да, сорри, Object-Relational Mapping.

Но сути это не меняет - вся логика при ORM выносится из СУБД. При большой базе, да еще в сложном проекте со сложной структурой данных это - самоубийство.

> они надеятся с таким названием на энтерпрайз? 0_o

А ты думаешь, что дриздль не может быть энтерпрайздль? В наш 21-й век, когда есть даже смертельные пинги энтерпрайз-класса?

ну ведь несерьезное название, а заказчики^Wдиректора любят глазами и ушами

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

Спорщиков спрошу - опять тенденция не ходить по ссылкам?

>Drizzle will have a micro-kernel architecture with code being removed from the Drizzle core and moved through interfaces into modules. Akers has already selected particular functionality for removal: modes, views, triggers, prepared statements, stored procedures, query cache, data conversion inserts, access control lists and some data types.

Drizzle получит микроядерную архитектуру, в которой [функциональный] код будет удален из ядра Drizzle и перенесен через интерфейсы в модули. Akers уже отобрал определенные части кода для переноса: views, triggers, prepared statements, stored procedures, query cache, data conversion inserts, access control lists и некоторые типы данных.

Далее святататствуем - идем по ссылке из ссылки: http://bazaar.launchpad.net/~drizzle-developers/drizzle/development/annotate/...

Читаем:

A micro-kernel that we then extend to add what we need (all additions come through interfaces that can be compiled/loaded in as needed). The target for the project is web infrastructure backend and cloud components.

Кто не понимает, перевожу: целью проекта является создание и расширение микроядра, чтобы оно могло грузить все, что потребуется для базы дополнительно. Т.е. кому что не надо, грузить не будет.

Понятно, что в микроядре не будет большей части функционала (о чем там и сказано, но автор новости не сообразил).

Ну и на сладкое:

We are focusing on multi-core architecture. This is not designed to run on a wrist watch (hint, go use SQLite). We support both 32bit and 64bit but the class of machine we are targetting is 64bit. We are making design decisions which assume very large amounts of RAM will be made available to the DB.

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

Без реплик в том виде, в каком они сейчас есть.

Ну, это в корне меняет дело :)

Шо-то я тоже по ссылкам ходить перестаю. Не порядок :)

Hу и чего неправильного?

> Drizzle получит микроядерную архитектуру, в которой [функциональный] код будет удален из ядра Drizzle и перенесен через интерфейсы в модули. Akers уже отобрал определенные части кода для переноса: views, triggers, prepared statements, stored procedures, query cache, data conversion inserts, access control lists и некоторые типы данных.

Это ты пишешь. А сами они говорят:

> A micro-kernel that we then extend to add what we need (all additions come through interfaces that can be compiled/loaded in as needed).

ТО есть *сначала все уберут*, а потом то что надо добавят. Разумно предположить что надо будет не всё ибо если надо будет все, нафига его убирать?

>При большой базе, да еще в сложном проекте со сложной структурой данных это - самоубийство.

Узким место практически всегда является база данных. Чем она быстрее тем лучше. Засовывание логики во внутрь не всегда дает ускорение - а лишь в том случае когда нужно таскать огромное количество данных из нее. Приведенный случай ничего такого не говорит.

query cache - это они зря погорячились, для веб-сайтов самое оно.

>Но сути это не меняет - вся логика при ORM выносится из СУБД. При большой базе, да еще в сложном проекте со сложной структурой данных это - самоубийство.

eBay — достаточно сложный проект?

Разработчики Какашки начали работу над ее форком - Дрисней.

вы читать умеете? уберут и уберут из ядра - вещи немного разные.

> mysql 3 ... нихрена не умел - зато очень быстро

Ха. Я могу ничего не уметь со скоростью, близкой к скорости света

>>Кстати, как ты, вообще логику работы ORM в описанном тобой случае представляешь?

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

>по поводу mview - здесь они не помогут: во-первых, они все-таки предназначены для DW а не для OLTP, во вторых не укладываются в логическую модель: вставляем в таблицу, а выбираем из mview

Ну не стоит совсем то тупить. ORM запросит через SQL нужные данные, а затем SQL-resultset замаппит в объекты чтобы проще работать было. При правильном написании на получание связанных объектов нужно 2 запроса, а не 1+N.

Если вычислимые аттрибуты можно посчитать на СУБД, то будет посчитано, иначе нужно тащить на апп-сервер и крутить в нем. ИМХО второе - глупость архитектора. ORM может делать объекты из результата хранимки, так что все что можно получить от СУБД может быть использовано как объект.

> у меня не сложный запрос, а простой, поскольку count(file), sum(size) будут сразу храниться в таблице с фильмами и будут считаться тригерами. Если Вам не западло из ORM заполнять эти же поля (то есть полностью вынести логику из БД) и поэтому тригеры Вам не нужны, то прекрасно, только сопровождать код и базу будет на порядок сложнее.

Триггера в общем случае ухудшают время INSERT / UPDATE и денормализуют БД. Это приводит к усложнению БД и ухудшению большинства характеристик. Потому нужно делать ТОЛЬКО если есть реальная необходимость и это серьезно увеличивает быстродействие.

PS ORM можно использовать вместе с триггерами, т.к. ORM это маппер рекордсетов в объекты и обратно :)

> у меня не сложный запрос, а простой, поскольку count(file), sum(size) будут сразу храниться в таблице с фильмами и будут считаться тригерами. Если Вам не западло из ORM заполнять эти же поля (то есть полностью вынести логику из БД) и поэтому тригеры Вам не нужны, то прекрасно, только сопровождать код и базу будет на порядок сложнее.

Опять же при денормализации нужно предусмотреть ситуацию "разсинхронизации" данных и пересчета вторичных данных по первичным. Т.е. кроме триггеров нужно еще набор хранимок пересчитываюзих по тому же алгоритму что и триггера. И каждый раз меняя триггер нужно менять хранимку.

> Кстати, об ОРМ: интересно, а как организовать на ее уровне обработку событий таблицы? :) ORM - это Object-Relational Model или кто-то думает иначе?

В ОРМ нет таблиц, потому вопрос ни о чем. В ОРМ можно организовать обработку событий объектов. Тип объекта != таблица.

ORM - Object-Relation Mapping. Фреймворк для автоматического заворачивания SELECT в набор объектов и сохранения объектов через INSERT / UPDATE.

>> как-как, в ORM придется обратиться к объекту фильм, для него найти соответствующие объекты "файл", посчитать их количество и размер

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

Лажа. правильный ОРМ (зависит от реализации) сделает селект только на нужные поля и только они и будут подниматься с БД. При желании можно использовать прямой SQL и уже его маппить в объекты.

> Да, сорри, Object-Relational Mapping.

> Но сути это не меняет - вся логика при ORM выносится из СУБД. При большой базе, да еще в сложном проекте со сложной структурой данных это - самоубийство.

Логика распределяется между СУБД и АппСервером. В сложном проекте это может иметь и преимущества и недостатки. Нжуно рассматривать ВСЕ варианты и использовать лучший.

К примеру на Java кластер J2EE servers обменивается информацией между нодами и если ОДНА нода знает ответ на запрос, то другая уже не полезет в СУБД, потому общая система СУБД+Апп может, при правильной архитектуре, выдерживать большую нагрузку чем сама СУБД. Нужно тестить ;)

>Но сути это не меняет - вся логика при ORM выносится из СУБД. При большой базе, да еще в сложном проекте со сложной структурой данных это - самоубийство.

Как раз таки наоборот. Лечить не понятное поведение логики в субд на больших объемах данных занятие очень увлекательное. Особенно во всяких чудо_мега_Ынтерпрайз аля Оракл и ДБ2.

>ТО есть *сначала все уберут*, а потом то что надо добавят. Разумно предположить что надо будет не всё ибо если надо будет все, нафига его убирать?

Читай все целиком. Они это планируют вынести. Цель их действий - убрать все из микроядра. Цель действий других - впихнуть все обратно в виде модулей через интерфейсы. Об этом сделана выжимка в самой статье. А в faq объясняется что и как. Капишь?

Молодцы, ребята!

В условиях современного зоопарка и динамических требований, очень ссыкотно затачивать ПО на определённую СУБД. Соотв., от БД нужно использовать "общий минимум" - таблицы, да запросы. Вот такой форк МуСкуЛя очень даже нужен!

Я сам юзаю MS SQL 2005, но опять же - только таблицы, так что переход на какой-нть Орасл - не проблема. Рекомендации лучших виндовозов. :)

> Триггера [...] денормализуют БД.

каким это образом? структуру таблиц меняют??

название стремное, а так проект обещает быть интересным, вопрос только в том насколько оно останется совместимым с MySQL в рамках обычного использования (www и проч.)

>> Триггера [...] денормализуют БД.

>каким это образом? структуру таблиц меняют??

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

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

Ничего не мешает в ORM-е повесить сигнал на сохранение записи и уже по этому сигналу делать апдейт.

ActiveRecord из Ruby on Rails кошерен

> В условиях современного зоопарка и динамических требований, очень ссыкотно затачивать ПО на определённую СУБД. Соотв., от БД нужно использовать "общий минимум" - таблицы, да запросы. Вот такой форк МуСкуЛя очень даже нужен!

А самый универсальный подход - flat files. Пока в базе доступ к данным на изменение не идет через stored procs - особой эффективности ждать бесполезно. Очень советую ознакомиться с теорией - почему и как это делается.

> Я сам юзаю MS SQL 2005, но опять же - только таблицы, так что переход на какой-нть Орасл - не проблема. Рекомендации лучших виндовозов. :)

Это действительно рекомендации виндовоза, ибо MS SQL - один из худших серверов на этой планете. Хуже только MySQL, вероятно. Попробуйте Postgres, Oracle, Informix - поймете почему. Но пробовать надо на достаточно больших базах (1Gb+) со сложной структурой и сложной обработкой данных. На маленьких базах, полностью лежащих в памяти, даже такое убожество как MSSQL работает быстро. Хотя идиотизм PL/SQL в MSSQL это не лечит.

>>ТО есть *сначала все уберут*, а потом то что надо добавят. Разумно предположить что надо будет не всё ибо если надо будет все, нафига его убирать?

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

Кто такие эти другие? Ссылку на их хоумпейдж приведи пожалуйста? По ссылке которую ты сам привел: http://bazaar.launchpad.net/%7Edrizzle-developers/drizzle/development/annotat...

Читаем:

23 * So what are the differences between is and MySQL? 24 1 25 201.1.1 No modes, views, triggers, prepared statements, stored procedures, query cache, 26 data conversion inserts, ACL. Fewer data types. Less engines, less code.

про то, чтобы сделать модуль с views ни слова не написано...

> А форкнули тройку?:))

+1

> А самый универсальный подход - flat files. Пока в базе доступ к данным на изменение не идет через stored procs - особой эффективности ждать бесполезно. Очень советую ознакомиться с теорией - почему и как это делается.

Интересные теории наверно... Не можете ли намекнуть, как доступ к данным на изменение ускорится от использования stored procs? Парсинг запроса? Тут можно prepared statement'ом обойтись, но вообще время парсинга и оптимизации заметно только если у вас таблицы по 100 записей...

> Это действительно рекомендации виндовоза, ибо MS SQL - один из худших серверов на этой планете. Хуже только MySQL, вероятно. Попробуйте Postgres, Oracle, Informix - поймете почему.

А без взятия на понт, чего вам не хватает в SQL Server что есть в PostgreSQL? Отсутсвия встроенной поддержки репликации?

> Не можете ли намекнуть, как доступ к данным на изменение ускорится от использования stored procs? Парсинг запроса? Тут можно prepared statement'ом обойтись, но вообще время парсинга и оптимизации заметно только если у вас таблицы по 100 записей...

Намекаю. Если у ваши модификации данных включают только insert или update, без особых связей изменений данных друг с другом - то prepared statement вам в руки. А вот если при изменении информации надо проверить уже существующие данные в разных таблицах, или изменять данные сразу в нескольких связанных таблицах - тут stored proc дает преимущество за счет отсутствия data round trips. Это не говоря уже о том, что гораздо проще оптимизировать несколько процедур, которые используются в сотнях мест, чем сотню AdHoc запросов в разных местах.

>Ну да, давайте все перенесем в application level или вообще забудем о базе данных - нах она вообще нужна? Ъ-сайтописатели в СУБД вообще не нуждаюццо :ржачь: :D

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

Да, есть такая быдлоконторка ebay, у них так и сделано. Ламеры, что ни говори...

> А без взятия на понт, чего вам не хватает в SQL Server что есть в PostgreSQL? Отсутсвия встроенной поддержки репликации?

Практически все, чем так гордится MS SQL, работает нормально в очень ограниченных условиях. Неприлично медленно MS SQL работает на updates & deletes, если в базе типичны многоуровневые foreign keys. Два-три уровня еще ничего, четыре и выше начинают тормозить жутко. Если таблицы не помещаются в память целиком, торможение идет в десять раз и больше. Эксперимент на select по таблице в 50Gb phys.size блокировал сервер на 15-20 минут.

Совсем никакой MSSQL в режиме OLTP. Скорость на insert примерно 160..200 транзакций в секунду. Это можно ускорить, если делать ввод со многих threads одновременно. При 10 threads уже получается около 600 t/sec, при 50 - примерно 1400 t/s. При этом сервер буквально неспособен делать что-то еще.

Сравниваем с Informix/Linux (1900..2200 t/s) или Postgres (1400..1600 t/s) на том же оборудовании. Причем у обоих результат мало меняется при кол-ве threads от 1 до 20..30, потом начинает снижаться, и при 50 threads падает на 5%-7%.

А теперь подумайте - многие ли задачи легко распараллеливаются? И если i/o сервера блокировано multiple threads - сколько запросов будут банально ждать в очереди?

Вообще список проблем в MSSQL займет многие страницы. Многие из этих проблем были еще в MSSQL 6.x.

Что же касается встроенной репликации - это еще то тормозилово. Я делал репликацию на Informix - работает на порядок быстрее. Буду скоро в Postgres делать что-то подобное, сравню. Мне ведь все равно - встроенная она или нет, лишь бы работала и не тромозила.

> А вот если при изменении информации надо проверить уже существующие данные в разных таблицах, или изменять данные сразу в нескольких связанных таблицах - тут stored proc дает преимущество за счет отсутствия data round trips.

Итого, всего лишь data round trips. То есть, если у вас есть возможность выполнить кусок вашего приложения, общающийся с БД, на той же машине, где расположена БД - преимущество stored proc минимально?

> Это не говоря уже о том, что гораздо проще оптимизировать несколько процедур, которые используются в сотнях мест, чем сотню AdHoc запросов в разных местах.

Если в приложении появилась сотня adhoc-запросов, которые на самом деле сводятся к всего нескольким процедурам - ССЗБ, сейчас чай все языки программирования вынос общего кода в функции поддерживают.

А если сто запросов к нескольким функциям не сводятся, о чем тогда разговор?

> Практически все, чем так гордится MS SQL, работает нормально в очень ограниченных условиях. Неприлично медленно MS SQL работает на updates & deletes, если в базе типичны <skip>

cпасибо за информативный пост :-) я MSSQL очень ограниченное знакомство имел...

Хотя бы набери в гугле эти слова и почитай что они значат. Звучит как "юзайте автомобиль или 95-ый бензин"

> Хотя бы набери в гугле эти слова и почитай что они значат. Звучит как "юзайте автомобиль или 95-ый бензин"

Автор, очевидно, имел в виду именно EJB3 Persistence, а не вообще EJB3.

И ты тоже гугль почитай.

> вся логика при ORM выносится из СУБД.
> При большой базе, да еще в сложном проекте со сложной структурой данных это -
> самоубийство.

1. мягко говоря 4.2

2. проект проекту рознь. иногда оказывается что написать многоразвложенный запрос оказывается быстрее, а иногда вытащить _ВСЮ_ таблицу на application server и там поизгаляться над данными.

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

Найти почему при записи в столбец А строки с ИД=98723423 значения 2 там оказывается 18, а при записи туда значения 4 там оказывается 42 - это задача может сперва показаться вопросом уровня ответа на смысл вселенной и всего-всего.

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

PS: ОРМ - хороша только тогда, когда сценарий работы приложения вписывается в юзкейс тех, кто писал ОРМ. Если надо что-то неожиданное, то ОРМ идет лесом вприпрыжку. А так как под ОРМ надо еще и базу проектировать (очень часто денормализовать приходится) - то ОРМ вообще зло.

mysql юзают только толпы студентов ибо название знакомое... тфу на него и его говнофорки

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

угу. особенно если команду разработчиков в детстве лупили по рукам за намеки на строчки документации и комментариев

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

у меня складывается мнение, что все кто пропагандируте ORM знают SQL на уровне select * from table.

> Итого, всего лишь data round trips. То есть, если у вас есть возможность выполнить кусок вашего приложения, общающийся с БД, на той же машине, где расположена БД - преимущество stored proc минимально?

Не совсем.

Во-первых, сама идея транспортировки данных из сервера вместо использования внутри наружу уже ушербна, так как проходит через несколько уровней доступа к данным. К примеру, если доступ идет черз ODBC, то данные проходят через сокет, потом через драйвер ODBC (который сам по себе достаточно медленен), потом через ваш собственный уровень абстракции.. В моей практике замена ODBC драйвера на нечто более заточенное под задачу приводило к выигрышу от 5% до 40%. Основная причина - неуклюжие манипуляции в памяти в ODBC драйвере и уровнях абстракции.

Во-вторых, манипуляции с данными проще делать в языке, который именно под это и заточен.

Ну и в-третьих, создание уровня абстракции из stored procedures позволяет создать API системы, с четко выраженными правилами. Как правило, 90% программистов понятия не имеют о pros & cons разных способов написания одного и того же запроса. И не надо - не их это дело. Они умеют вызывать API-функции, дайте им эти функции, а вот оптимизацию оставьте на DBA или DB-developer. Тут куча преимуществ, как с точки зрения производительности, так и т.з. тестирования, документирования и тд.

Кстати, есть еще и просто вещи, которые без процедур сделать нельзя. Например - разграничение доступа на уровне строки. На уровне колонки можно еще сервером разрулить (Postgres этого не делает, правда, а жаль). А вот не разрешить никому доступ к строке или полю по условию в данных - это уж без процедур никак. Это можно прописать в программе, но тогда другая программа спокойно это обойдет. А в процедуре, созданной с security definer под dbowner, можно внутри все что надо выяснить, разрешить или запретить доступ, и при этом любая программа с наружи будет бессильна что-то сделать. Прямой доступ к данным, в этом случае, надо запретить (select/update/delete).

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

Слушай - ты может у нас работаешь?:) У нас тут есть 15 летний мегапроект с процедурами и триггерами который надо развивать - хер поймешь что там куда происходит - все значения мистические, обновляется пол базы по тригерам - тут записал - там появилось(жванецкий мля) - никто из ныне живущих не знает почему так и на кой хер, и кому оно вообще надо....

кому щас нужено оно вобще? кому надо хорошую базу юзают postgresql, кому надо недобазу юзают sqlite... разве не так?