The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Проект MariaDB реализовал поддержку режима атомарной записи ..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Проект MariaDB реализовал поддержку режима атомарной записи ..."  +/
Сообщение от opennews (ok) on 01-Май-13, 12:12 
Разработчики проекта MariaDB, в рамках которого развивается СУБД продолжающая развитие кодовой базы MySQL, представили (http://blog.mariadb.org/mariadb-introduces-atomic-writes/) реализацию нового режима атомарной записи (https://kb.askmonty.org/en/fusioniodirectfs-atomic-write-sup.../) (Atomic Writes) для хранилищ InnoDB и XtraDB.  Эффективность режима атомарной записи особенно заметна на системах с  SSD-накопителями, обеспечивающими низкое время отклика.


Например, выполнение OLTP-тестирования пакетом sysbench (100 Гб данных, 400 млн записей в 16 таблицах) показало, что при наличии от 8 одновременных потоков обработки запросов производительность нового режима на 25-30% опережает ранее применяемый режим двойной записи. Дополнительное задействование режима быстрого расчёта контрольных сумм в XtraDB позволяет довести выигрыш в скорости до 50%.

<center><a href="http://blog.mariadb.org/wp-content/uploads/2013/04/tps_rw.pn... src="http://www.opennet.dev/opennews/pics_base/0_1367387085.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>


Дополнительно можно отметить готовность (http://blog.mariadb.org/mariadb-10-0-2-alpha-now-available/) для тестирования экспериментального выпуска MariaDB 10.0.2 (https://kb.askmonty.org/en/mariadb-1002-release-notes/), в котором интегрированы патчи с поддержкой режима атомарной записи. Кроме того, поддержку нового режима планируется добавить в готовящийся к релизу стабильный выпуск MariaDB 5.5.31. Из других новшеств MariaDB 10.0.2, по сравнению с выпуском 10.0.1 (http://www.opennet.dev/opennews/art.shtml?num=36104), можно отметить:


-  Новое хранилище Connect (https://kb.askmonty.org/en/connect/), позволяющее организовать доступ к произвольным локальным или удалённым данным, в виде, как если бы они были сохранены в таблице. Например можно ассоциировать содержимое виртуальной таблицы с данными из файла в определённом формате;
-  Поддержка (https://mariadb.atlassian.net/browse/MDEV-26) глобальных идентификаторов транзакций;
-  Возможность использования проверки IF (NOT) EXIST для выражений ALTER TABLE;
-  Дополнительные оптимизации выполнения вложенных запросов, например преобразование выражений "NOT EXISTS" в блоки "IN";
-  Хранилище Sequence (https://kb.askmonty.org/en/sequence/) для формирования виртуальных таблиц, заполненных  возрастающими или убывающими последовательностями (например,  seq_1_to_5 или seq_5_to_1_step_2).

URL: http://blog.mariadb.org/mariadb-introduces-atomic-writes/
Новость: http://www.opennet.dev/opennews/art.shtml?num=36835

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +1 +/
Сообщение от pavlinux (ok) on 01-Май-13, 12:12 
>  особенно заметна на системах с SSD-накопителями

Ага, - SSD быстрее сдохнет :)

---
https://kb.askmonty.org/en/fusion-io-introduction/

> FusionIO/DirectFS atomic write support

Ну конечно, накупили себе там FusionIO теперь пиписками махают. Нет чтоб тестить и разгонять на ATA/33

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +/
Сообщение от Аноним (??) on 01-Май-13, 12:21 
Хранить базы на SSD - опухоль головного мозга
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +/
Сообщение от pavlinux (ok) on 01-Май-13, 13:10 
Fusion-IO и SSD, обычно, для кэша и каких-то временных файлов используют.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +/
Сообщение от rshadow (ok) on 01-Май-13, 13:17 
годиков через 5 все только на них и будут хранить
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

9. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +/
Сообщение от Карбофос (ok) on 01-Май-13, 23:24 
у меня тут за годик ёмкость ssd уменьшилась с 4 гиг до 3.4. много циклов зписи практически ежедневно - примерно по 1 гигу новых файлов. хотите ушатать быстрее - записывайте интенсивнее.
другая "фишка" ssd заключаеся в том, что экономят даже на смоле для текстолита, через некоторое время он вбирает в себя достаточное количество влаги и...
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

10. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +/
Сообщение от Аноним (??) on 02-Май-13, 03:12 
trim включен ? у ssd есть оперативка ddr3 для кэширования блоков ?
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +1 +/
Сообщение от Аноним (??) on 02-Май-13, 17:10 
Вся эта ваша ссдетень почти упёрлась в потолок. А жестким дискам ещё есть куда стремиться - hamr, bpm, tdmr и прочие радости.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  –1 +/
Сообщение от хзкто2 on 01-Май-13, 16:56 
> Хранить базы на SSD - опухоль головного мозга

Почему бы и не хранить. На мастере база на SSD или вообще в памяти, бинлоги на HDD, слейв целиком на HDD - вполне рабочая схема. Да и рейд из SSD никто не отменял. HDD уже прошлый век, они хороши только для хранения.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

12. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +2 +/
Сообщение от Аноним (??) on 02-Май-13, 19:53 
>> Хранить базы на SSD - опухоль головного мозга
> Почему бы и не хранить. На мастере база на SSD или вообще
> в памяти, бинлоги на HDD, слейв целиком на HDD - вполне
> рабочая схема. Да и рейд из SSD никто не отменял. HDD
> уже прошлый век, они хороши только для хранения.

Как ты себе представляешь себе 100 Тб массив SSD? Сколь он будет стоить - догадываешься? ИЛи ты считаешь, что все СУБД - это твои базеночки на мускуле? Ну так я тебя разочарую. Средней паршивости сервер банкоматов в небольшом таком банчке 2 уровня - 6-9 Тб вполне себе OLTP, причем с хорошим таким откликом. Если такой рэйдик гекнется в масштабах, скажем, вашего паршивого Сбера - догадываешься, чего будет? Ах, ты из бэкапа десяток Тб мгновенно вернешь? Ну-ну...

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

13. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +/
Сообщение от Фигов on 02-Май-13, 20:17 
Бедняжка убогонький! как же ты работаешь в банке на мускуле-то?
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

15. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +/
Сообщение от хзкто2 on 03-Май-13, 08:08 
> Как ты себе представляешь себе 100 Тб массив SSD? Сколь он будет
> стоить - догадываешься?

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

> Средней паршивости сервер банкоматов в небольшом таком банчке 2 уровня - 6-9 Тб
> вполне себе OLTP, причем с хорошим таким откликом.

Ты же понимаешь, что это абсолютно бесполезная информация без знания количества и сложности транзакций, по распределению времени обработки, по железу. Хотя бы скажи сколько там произвольных iops, какой рейд и сколько ОЗУ, тогда можно будет поговорить предметно.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

16. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +/
Сообщение от anonymous (??) on 03-Май-13, 10:44 
OLTP база (про которые разговор, раз SSD затронули) на одном узле без шардинга на 100ТБ - вот он жизненный пример, как аргумент в споре!
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +/
Сообщение от Лентяй (??) on 03-Май-13, 02:01 
>>  особенно заметна на системах с SSD-накопителями
> Ага, - SSD быстрее сдохнет :)
> ---
> https://kb.askmonty.org/en/fusion-io-introduction/
>> FusionIO/DirectFS atomic write support
> Ну конечно, накупили себе там FusionIO теперь пиписками махают. Нет чтоб тестить
> и разгонять на ATA/33

Главное что новость написана так, будто эти самые атомарные операции записи теперь поддерживаются везде, а не только для этого самого FusionIO/DirectFS. Нехорошо.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +2 +/
Сообщение от Аноним (??) on 01-Май-13, 12:47 
Лучше бы нормальный sequence запилили, как в том же постгресе
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +1 +/
Сообщение от Аноним (??) on 01-Май-13, 14:52 
> Новое хранилище Connect, позволяющее организовать доступ к произвольным локальным или удалённым данным

Сколько ж я этого ждал смотря в сторону FEDERATED Storage Engine. Теперь FEDERATED Storage Engine должен окончательно умереть.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +1 +/
Сообщение от Аноним (??) on 01-Май-13, 15:00 
А еще хочется чтобы TokuDB был из коробки.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Проект MariaDB реализовал поддержку режима атомарной записи ..."  +/
Сообщение от Ape (ok) on 14-Май-13, 11:55 
>Как ты себе представляешь себе 100 Тб массив SSD? Сколь он будет стоить -
>догадываешься? ИЛи ты считаешь, что все СУБД - это твои базеночки на мускуле?
>Ну так я тебя разочарую. Средней паршивости сервер банкоматов в небольшом таком
>банчке 2 уровня - 6-9 Тб вполне себе OLTP, причем с хорошим таким откликом.
>Если такой рэйдик гекнется в масштабах, скажем, вашего паршивого Сбера -
>догадываешься, чего будет? Ах, ты из бэкапа десяток Тб мгновенно вернешь?
>Ну-ну...

Что за идиот проектировал базу этого банка? Что в ней хранится на 100ТБ или даже на 6-9ТБ? Очевидно, что забита говном проектировщика и программиста... Математиков совсем не стало среди программистов, одни двоечники. Мануалы не читают и ставят в банках свои говноподелия. А, MySQL хорший сервер. Нечего на него пургу гнать. Не хуже Оракла и уж гораздо лучше MSSQL.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру