Круто!

Расшифруйте для тупого фразу "с учетом возможностей современного железа" - типа тормозить будет больше или просто оптимизацию включат под новые процы или еще там памяти предлагается много жрать? Что имелось ввиду-то?

Т.е. в mysql появится то, что уже с 1812 года есть в PostgreSQL? Нах он (mysql) тогда нужен?

Джим Старки начинает делать из MySQL'я Firebird ;-)

Falcon это и есть postgres (MVCC) но только в оперативке, с автоматическим сохранением/загрузкой на диск.

В результате и транзакции и высокая скорость. Но память жрёт, тк не commit'нутые данные писатся на диск даже не пытаются.

Мда. В Oracle задумались: а не пора ли реализовать ли в MySQL то, что в Postgres было 7 лет назад? А в Oracle, Informix, etc, и 12 лет назад?

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

Что-то я не пойму... MySQL будет заниматься оптимизацией доступа к дорожкам веника? Бардаааак...

При чем тут Oracle?

> Что-то я не пойму... MySQL будет заниматься оптимизацией доступа к дорожкам веника? Бардаааак...

Нет. Он просто, по возможности, будет писать данные большими кусками.

> При чем тут Oracle? > VladimirP * (*) (05.02.2007 12:54:53)

В октябре 2005 Oracle прикупил финскую Innobase Oy, которая делает движок InnoDB, на котором сидит MySQL.

Рейзер был прав.

> Что-то я не пойму... MySQL будет заниматься оптимизацией доступа к дорожкам веника? Бардаааак...

"Если вы используете дополнительный слой для хранения данных, у вас просто плохая файловая система." (Г. Рейзер)

>"Если вы используете дополнительный слой для хранения данных, у вас просто плохая файловая система." (Г. Рейзер)

Если Вы бездумно цитируете чужие мысли, значит у вас не хватает своих.

> Falcon это и есть postgres

Откуда дровишки?

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

Да, MySQL - наше фсио!

> В октябре 2005 Oracle прикупил финскую Innobase Oy, которая делает движок InnoDB, на котором сидит MySQL

Но это не значит, что Оракл будет хоть что-то делать для MySQL.

Зато, в принципе, Оракл может поменять лицензию на InnoDB, и вот тогда Мускулю придется срочно искать новый транзакционный движок. Для того и Falcon, чтобы в луже не оказаться ненароком.

>В результате и транзакции и высокая скорость.

Где?

http://dev.mysql.com/doc/falcon/en/se-falcon-limits.html

* Serializable isolation levels are not supported.
* Distributed transactions are not supported.
* Lock timeout configuration is not supported.
* Online backup is not supported
* Foreign key support is currently not available.


Превед!

>Откуда дровишки?

Оттуда. В Falcon имплементируется версионный механизм. А догадайся какое коренное отличие мускуля от постгреса было?

> * Online backup is not supported > * Foreign key support is currently not available. > Превед!

Да - действительно "превед" ...

> Оттуда. В Falcon имплементируется версионный механизм.

А хто тебе сказал, что версионный механизм есть ТОЛЬКО в постгресе??? В интербейсе (и во всех его клонах) есть с самого начала, в MS SQL появился недавно...

>А хто тебе сказал, что версионный механизм есть ТОЛЬКО в постгресе???

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

А не проще было бы форкнуть фиребирд?

Сделают и бекап горячий и внешние ключи, наверняка.

А остальное, так ли уж кому надо?

>А не проще было бы форкнуть фиребирд?

Действительно почему всегда изобретать нужно одно и тоже, тем более, AFAIK, Firebird лицензией не пугает никого... MySQL дал бы кластеринг всякие фичи, а Firebird свое хранение, может быть и получилось бы что-то интересное.

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

Вы чего-то не доглядели -- engine MyISAM ни куда не исчезнет, какой движек захотите, такой и используйте

>А остальное, так ли уж кому надо?

Serializable Isolation Level - это самый жестокий уровень транзакций при котором ты гарантировано не получишь интерференции транзакций ни в каком виде. Все остальные допускают влияние друг на друга. http://en.wikipedia.org/wiki/Isolation_(computer_science)

Его нет.

Отсутсвие DTP делает этот движок мертвым для энтерпрайза изначально.

> Firebird свое хранение, может быть и получилось бы что-то интересное.

Firebird'у уже 100 лет как обещают многопоточность, а воз и ныне там, только и отодвигают на следующую версию, плюс проблемы с транзакциями.

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

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

> Превед!

> Отсутсвие DTP делает этот движок мертвым для энтерпрайза изначально.

Из TFA: "В настоящее время (5.2.0-alpha), хранилище находится в состоянии alpha, т.е. в нем нет всей запланированной функциональности"

В знаете, я сейчас занимаюсь небольшим тестированием MySQL4, MySQL5 и PostgreSQL8.2.

Это песня. Нет, это ПЕСНЯ. Постгрес на основных запросах медленнее MySQL в полтора-два раза.

Но у MySQL по ходу действа проявилась вообще просто потрясающая пенка, от которой жить сразу резко-резко стало скучно-скучно.

В знаете, я сейчас занимаюсь небольшим тестированием MySQL4, MySQL5 и PostgreSQL8.2.

Это песня. Нет, это ПЕСНЯ. Постгрес на основных запросах медленнее MySQL в полтора-два раза.

Но у MySQL по ходу действа проявилась вообще просто потрясающая пенка, от которой жить сразу резко-резко стало скучно-скучно.

>Из TFA: "В настоящее время (5.2.0-alpha), хранилище находится в состоянии alpha, т.е. в нем нет всей запланированной функциональности"

Это можно сказать о любой программе в которой чего-то нет:)

OpenSuSe Linux находится в промежуточной версии 10.2, потому нет запланированного фотошопа:)

В знаете, я сейчас занимаюсь небольшим тестированием MySQL4, MySQL5 и PostgreSQL8.2.

Это песня. Нет, это ПЕСНЯ. Постгрес на основных запросах медленнее MySQL в полтора-два раза.

Но у MySQL по ходу действа проявилась вообще просто потрясающая пенка, от которой жить сразу резко-резко стало скучно-скучно.

>>Из TFA: "В настоящее время (5.2.0-alpha), хранилище находится в состоянии alpha, т.е. в нем нет всей запланированной функциональности"

>Это можно сказать о любой программе в которой чего-то нет:)

Сказать можно всё. Но почему-то не говорили, что, например, MySQL 3.x был альфой из-за того, что в нем не было многоверсионности.

>Но почему-то не говорили, что, например, MySQL 3.x был альфой из-за того, что в нем не было многоверсионности.

Угу. Я пару лет назад читал спеку X/Open DTP (хотел прикрутить JTA с поддержкой XA к своему сторажу) - чето сомневаюсь что поддержка распределенных транзакций такая штука, которую можно добавить в late development - разве что она там уже есть, но недоделана.

> Я пару лет назад читал спеку X/Open DTP (хотел прикрутить JTA с поддержкой XA к своему сторажу)

Разве такие вещи делаются на уровне хранилища данных? Насколько я знаю, это механизм более высокого уровня.

В знаете, я сейчас занимаюсь небольшим тестированием MySQL4, MySQL5 и PostgreSQL8.2.

Это песня. Нет, это ПЕСНЯ. Постгрес на основных запросах медленнее MySQL в полтора-два раза.

Но у MySQL по ходу действа проявилась вообще просто потрясающая пенка, от которой жить сразу резко-резко стало скучно-скучно.

>Разве такие вещи делаются на уровне хранилища данных? Насколько я знаю, это механизм более высокого уровня.

Более. Но движки почему-то то поддерживают, то не поддерживают.

http://dev.mysql.com/doc/refman/5.1/en/pluggable-storage-overview.html

Может, теперь в firefox, наконец, заменят sqlite на mysql? А то lite - не по-пацански как-то...

>Serializable Isolation Level - это самый жестокий уровень транзакций при котором ты гарантировано не получишь интерференции транзакций ни в каком виде. Все остальные допускают влияние друг на друга.

Ну и ладно и хрен с ней :) Но преимущества которые он даёт по сравнению с Read-commited не стоят его недостатков. Хотя бы потому что СУБД может запросто оборвать транзакцию, по причине того что ей не удалось сериализировать (упорядочить) транзакции. Много ли программ имеют настолько продвинутую обработку ошибок, способную повторить всю транзакцию заново?

Ну и ещё один основной недостаток seriazable - это то что все транзакции исполняются последовательно, что попросту запрещает паралеллизм, убивая производительность. Так что уровня следует избегать.

> ещё один основной недостаток seriazable - это то что все транзакции исполняются последовательно, что попросту запрещает паралеллизм

Ты по ссылке-то сходил? "AS IF all transactions in the system had executed serially". На многоверсионнике все транзакции чтения можно исполнять параллельно. С транзакциями записи может быть так и сяк, но "попросту запрещает параллелизм" - это чушь.

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

А мы думали это твой быстрый мыскыль глюкнул :)

PS: Тестировал тоже самое, даже SQL-ки как у тебя .... постгрес _всегда_ рвет мыскыль как минимум в 3 раза ....


:)

>Много ли программ имеют настолько продвинутую обработку ошибок, способную повторить всю транзакцию заново?

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

>Так что уровня следует избегать.

Тем не менее он must be для многих critical mission приложений. Для форумов конечно неважно.

> На многоверсионнике все транзакции чтения можно исполнять параллельно.

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

О! Любопытно.

А откуда уважаемый знает, что и как у меня сделано в тестах? :-)

>А откуда уважаемый знает, что и как у меня сделано в тестах? :-)

А у тебя пароль к руту это логин наоборот ;)

Ох... :-( Догадались-таки фашисты!!! :-(

Я сменю, если смогу!
Вы ведь меня простите, да?

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

Умгу. Не спорю. :-)

<offtopic>
Передавай привет Червю. А то давно я его не видел. :-)
</offtopic>

а чо за пенка-то, а?