Вышел (http://permalink.gmane.org/gmane.comp.db.mysql.announce/478)  релиз MySQL Community Server 5.0.81 (http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0-8...), список изменений насчитывает исправление более 100 ошибок из которых 30 приводили к краху серверного процесса, а 2 ошибки были связаны с исправлением проблем безопасности. Но при внимательном рассмотрении большинство записей в списке изменений совпадают с изменениями в релизах 5.0.77 (http://www.opennet.me/opennews/art.shtml?num=20348) и 5.0.75 (http://www.opennet.me/opennews/art.shtml?num=19512), при выборке из репозитория исходных текстов обнаружено около 20 исправлений. Загрузить (http://dev.mysql.com/downloads/mysql/5.0.html) новую версию можно в исходных текстах и в виде бинарных сборок для всех популярных платформ.

Несколько новых заметок по MySQL:

-  "RAID vs SSD vs FusionIO (http://www.mysqlperformanceblog.com/2009/05/01/raid-vs-ssd-v.../)" - результаты сравнения производительности MyS...

URL: http://permalink.gmane.org/gmane.comp.db.mysql.announce/478
Новость: http://www.opennet.me/opennews/art.shtml?num=21601

• идиоты,Аноним, 14:08 , 05-Май-09
• Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,Avatar, 14:23 , 05-Май-09
  • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,Alexander, 11:11 , 06-Май-09
• Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,olex, 14:30 , 05-Май-09
• Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов,open, 16:09 , 05-Май-09
  • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов,geekkoo, 06:35 , 06-Май-09
• Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,igorsia, 16:15 , 05-Май-09
• Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,pavlinux, 17:07 , 05-Май-09
  • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,TS, 17:33 , 05-Май-09
    • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,pavlinux, 18:07 , 05-Май-09
      • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,TS, 18:15 , 05-Май-09
      • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,mmm, 19:04 , 05-Май-09
        • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,User294, 21:39 , 05-Май-09
          • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,x11term, 06:15 , 06-Май-09
          • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,Аноним, 15:10 , 06-Май-09
            • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,User294, 13:38 , 07-Май-09
          • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,anonymous, 15:48 , 06-Май-09
            • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,anonymous, 16:01 , 06-Май-09
            • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,Аноним, 19:03 , 06-Май-09
            • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,User294, 13:28 , 07-Май-09
  • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,Поэт битов и байтов, 18:07 , 05-Май-09
    • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,pavlinux, 18:12 , 05-Май-09
• Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,User294, 21:11 , 05-Май-09
  • Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,Ivan, 21:38 , 05-Май-09
• Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,Аноним, 15:20 , 06-Май-09
• Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов...,azz, 10:42 , 07-Май-09

Сравнили экспериментальную шнягу с продакшн релизом постгреса 8.3....

Моё отношение к MySQL это уже не изменит, я за Postgresql.

А числовые unsigned-типы там принципиально не делают?
Только из-за unsigned-типов держу кое-какие базы в MySQL...

TokuDB проблемы:
1 TokuDB плохо масштабируется - плохо работает на многопроцессорных системах
2 INSERT и DELETE работают быстро, UPDATE - медленнее
3 пока что нет recovery logs

про ставбильность MySQL можно анекдоты сочинять)
http://sql.ru/forum/actualthread.aspx?tid=660905
раз в неделю подобные темы...
как только мы у нас не перегружали PgSQL
от питания до kill -9
Хранилище не бьется,
в отличии от MySQL у которого на ровной дороге,
Got error from table handler и досвидания...

Можно не сочинять. Цитата -
"Венда ХР СП2 ... была открыта база в dbForge я играл в ViceCity и комп повис, ребутнул его кнопкой Reset" и уже смешно.

А что еще сломали?
в 5.1 в очередной раз сломали MyISAM. Починят (как всегда) через годик.

SSD под SQL - кучеряво живут...

FusionIO под MySQL - вот это точно кучеряво живут. FusionIO стоят около $10K...

FusionIO: 160GB = 4800$.

Я к тому, что SSD дохнут как мухи, а FusionIO 24 года, при трафике 5Тб в день.

>FusionIO: 160GB = 4800$.
>
>Я к тому, что SSD дохнут как мухи, а FusionIO 24 года,
>при трафике 5Тб в день.

А 5k$ - это не кучеряво? :)

FusionIO - это разновидность SSD, только с другим (относительно того, к которому привыкло большинство) интерфейсом.

>FusionIO - это разновидность SSD, только с другим (относительно того, к которому
>привыкло большинство) интерфейсом.

Кстати говоря - представлять flash-диски как якобы-HDD, с якобы-секторами в 512 байтов, с сокрытием реальной физики флеша и прочая - очень идиотская идея на самом деле, т.к. чертовски усложняет оптимизацию по скорости.Благо, *реальная* физика флеша здорово отличается и ничего общего с 512 байтными секторами не имеет.Запись именно блока в 512 байтов - это в случае NAND гарантированный влет на тормознутый read-modify-write силами его встроенного контроллера, который в ответ на такой запрос внутри себя вот такую вот последовательность действий отпедалит. Соврав всем что это запись 1 512 байтового сектора, просто такая вот медленная.На самом деле это как минимум чтение 2 или сколько там Кб страницы, патч 512 байтов, в лучшем случае - запись.В хучшем это вообще erase целого eraseблока+только потом запись(страницы можно писать только последовательно и фиг его там знает, выполнится ли это условие или нет).Чего доброго запись будет даже более чем 1 страницы даже (если на стертом erase-блоке было не пусто+в зависимости от логики FTL).И все это будет отпедалено ради якобы-атомарной записи 512 байтов!Пи$#ец...

ЗЫ: кстати браво форматируя штукенции с флешом не стоит забывать что всего лишь небольшая лажа в формате aka выбор размещения структур наобум и ... можно просрать скорость В РАЗЫ.Если скажем блоки ФС придутся на границу страниц флеша так что на чтение\запись 1 блока ФС будет вместо 1 страницы читаться\писаться 2 - выйдет жутко неоптимально и скорость весьма хардкорно просядет.Кстати если обратить внимание - дефолтовая ФС на продаваемых картах памяти, флехах и прочая как правило очень своеобразно скроена.Она там неявно и втихаря подогнана под физику флешатины, так что блоки ФС (у фат - кластеры) не попадют на середину границы страниц.А служебные структуры (mbr, таблицы FAT) сделаны так что во первых, MBR живет в отдельном erase block (и поэтому никогда не попадает под read-modify-write логику и потому не может слететь при проблемах), во вторых FAT'ы выравнены на erase-block, и так далее.

Ни один "обычный" форматтер ни в 1 ос этим не заморачивается и потому при попытке переформатить флеш-диск (как минимум для usb-флех верно) или MMC\SD карту - можно получить очень говняный результат. Кому интересно - подробный гайд по ускоренному убиению и деградации флешек - воон там: http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device

P.S. а кто чувствует себя реально крутым и понимает как устроена та или иная ФС и как работает флеш - u're welcome: предлагается подумать над интересным вопросом: как оптимально разложить на флеш что-то более вменяемое чем дефективный и морально устаревший FAT32.Для FAT32 на вон той паге есть пример того как мануфактуреры флешек его раскидывают с оптимизацей под флеш.Ну как, а нам слабо что-то помощнее оптимально раскинуть?Я уже мозг над этим изрядно поломал.А вы?Да, производитель кстати может читерствовать: ему известна логическая организация чипаков флеша и логика работы FTL-уровня в контроллере.Нам остается только *гадать* на эту тему.Хотя на самом деле - можно произвести серию бенчмарков и на их основании прикинуть реальную структуру по их итогам (если записи хреново накладываются на структуру флеша - будет тормозно, если хорошо - будет быстро).

P.P.S. Кстати пользуясь случаем передаю привет цыркачу iZEN по части "оптимизации под флеш память".Теперь доходит что такое *настоящая* оптимизация файловой системы под флеш? :D. Грамотно положив лэйаут ФС на страницы и erase блоки можно достичь оптимальности в плане отсутствия лишней работы для контроллера флехи и минимума перезаписей из возможного.Вот за контроллер и сокрытие им структуры флеша хочется их всех слегка убить.Заметили насколько усложняется оптимизация из-за поддержки совместимости с механическими хардами на уровне логической организации?Суки.Надо ж так прогресс тормозить ради совместимости.

Regards, your Captain Obvious :D

...
>Суки.Надо ж так прогресс тормозить
>ради совместимости.
>
>Regards, your Captain Obvious :D

Ты ещё x86 вспомни ...

>с механическими хардами на уровне логической организации?Суки.Надо ж так прогресс тормозить
>ради совместимости.
>
>Regards, your Captain Obvious :D

ужас-ужас!!!
как все плохо)))
если не помнить, о том, что на ssd есть кэш и как правило от 64Мбайт.
и контроллеры как правило оптимизированы, под то что бы не перезаписывать, пока есть возможность сделать переалокацию )))

>если не помнить, о том, что на ssd есть кэш и как правило от 64Мбайт.

Только на хороших.На всяких там usb и прочая - такого нету.И кроме того - и на много его хватит при рандомных доступах по всей поверхности?У флеша seek time мелкий а потому в случае крутого диска есть соблазн наподдать ему параллельных запросов в разные участки, с этим как раз у механики проблемы.А вот тут то и будет опа.ФС считают что писать кусочками по 512 байтов в рандомные точки - вполне валидно в принципе.А то что это очень не здорово для носителя они могут и не знать.И не знают.Ну а уж о том чтобы выровнять структуры ФС на erase-block'и сэкономив флешу циклы перезаписи (и время на них) и подавно в обычном случае никто не думал.У жестких дисков то ничего такого нет.А большинство ФС делались именно под них.А контроллер скрывая детали физики флеша еще и делает такое выравнивание весьма негарантированной и нетривиальной операцией - кто ж документирует физическое устройство диска и как себя контроллер ведет там внутри?

>и контроллеры как правило оптимизированы, под то что бы не перезаписывать, пока
>есть возможность сделать переалокацию )))

Опять же - только хорошие контроллеры.Их таких не так уж много.И стоят диски от приличных производителей с таким контроллером - как задняя часть самолета.Зато всякого фуфла с примитивными контроллерами - навалом.Кроме того - опять же а как преаллокация переживает слет питания?Она логику журналирования не рушит?Журнал предполагает что если сказали нечто записать - это записано.А не то что железка где-то внутри себя будет ждать - а не допишут ли еще чего туда же.И, собственно, ФС в своем праве уповать на 512-байтные блоки.Или на что там еще.Не выровненое на страницы и erase-блоки, что было бы наиболее оптимально для флеша.

Кошмар как страшно.
Просветите нас темных.Команда dd, mkfs, format - обращаются напрямую к контроллеру flash, т.е прямо ему сообщают от по такому адресу проведем границу сектора. По его внутренним командам?
Или они работают через интерфейс неважно какой. USB, SATA, PCI(семейство)?

.... А дальше контроллеру устройства? Черещ интерфейс устройства?

(Ps. виноват.не дописал)

>Кошмар как страшно.
>Просветите нас темных.Команда dd, mkfs, format - обращаются напрямую к контроллеру flash,
>т.е прямо ему сообщают от по такому адресу проведем границу сектора.
>По его внутренним командам?
>Или они работают через интерфейс неважно какой. USB, SATA, PCI(семейство)?

))) смишной)

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

> Команда dd, mkfs, format - обращаются напрямую к контроллеру flash

Нет, конечно.Вот только проблема в том что они работают с этим флешом как с обычным носителем.Как будто бы у него 512-байтные сектора которые можно индивидуально адресовать и записывать.А по факту - никаких секторов в 512 байтов там нет.Изображаются варварской эмуляцией путем read-modify-write страницы (которая у нанда обычно 2 или 4 Кб например).При этом операция получается не только не атомарной - она еще и соседние сектора затрагивает.Потому что у нанда атомарные операции - только со страницами, никак не менее.А это более чем 512 байтов.На что софт не рассчитывает в общем случае.Могу себе представить ситуацию когда питалово слетит так что это будет в процессе read-modify-write и похерится не только записываемый сектор (на что софт вполне может рассчитывать) но и несколько соседних (на что софт ессно не рассчитывает, т.к. у обычных жестких дисков запись сектора в принципе атомарная операция и соседние сектора обычно никак не затрагивает). Получается и более тормозно чем могло быть и стремно.А обычные файловые системы раскидывают по дефолту структуры как угодно, только не так как это было бы удобно реальному физическому носителю.

Я три года назад заюзал для сервиса типо DNSBL'a - всё просто взлетело но стоил 8GB дисочек 8 же тонн 8-\
А теперь - 120 букашек :) Так что не - не кучеряво, скучно и обыденно живут :)

букашки, это граммы золота? SAS стоит 250$ и дальше.

> К сожалению исходные тексты TokuDB не открыты для публичного доступа.

Началось... и как это согласуется с GPL'ем? oO

Надо полагать не хуже чем DB2.

ребят просветите, кто РЕАЛЬНО понимает как это работает

в тесте
"MySQL Performance: MySQL 5.4 and other InnoDB engines @dbSTRESS Benchmark"
приведен конфиг постгре с такими параметрами
effective_cache_size = 48000MB    
shared_buffers = 24000MB

это вообще считается нормальным?
(особенно при 256GB RAM)

да и вот это
fsync = on
synchronous_commit = off
wal_sync_method = fdatasync
wal_buffers = 2MB
как-то настораживает...

или это нормально и так и должно быть?
я действительно плохо понимаю какое должно быть соотношение ворк_мем/кэш/буферс

В
http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0-8...

For InnoDB tables, ORDER BY ... DESC sometimes returned results in ascending order. (Bug#37830)

;)