авторNow, enjoy more freedom with IBM Db2 Community edition. With the Db2 11.5.5, we have removed the 100 GB storage restrictions in Db2 Community edition . The latest version of IBM Db2 Community edition is free forever and is restricted with 4 Cores and 16 GB of memory with Community support. This means you can develop and test Db2 without any licensing cost.


https://karthik-g.medium.com/database-choices-made-easy-with-ibm-db2-2b9201c349c7

Копия: http://www.freezepage.com/1618442256AGHXRFAXLE

И feature matrix стала почти одинаковой для всех редакций:
https://www.ibm.com/docs/en/db2/11.5?topic=editions-functionality-in-db2-product-db2-offerings

Копия:
https://archive.is/0oLig

Я так понял, что от старшей редакции community теперь вообще не отличается ничем кроме аппаратных лимитов на CPU и оперативку?

Хотя еще, наверно возможность осуществить "звонок другу" в поддержке IBM, может быть нужен кому-то.
Хотя вот за 15 лет опыта работы с DB2 звонил им только один раз в самом начале работы, когда мне поломали оперативку на сервере, даже не проходил memtest - осыпался в красное.

Но ведь чем меньше официальной поддержки, тем больше спрос на freelance админов DB2 :)
Ессно IBM бы тут не помогла, но DB2 настойчиво не хотел падать, а тупил и вис на таком глючном сервере.
Наконец когда DB2 соизволил уйти в segfault через несколько дней, я сообразил запустить memtest, забавно было, что сервер с ECC оперативкой не прошел memtest, но при этом продолжал пытаться работать ...
Кстати, DB2 ведь при записи данных на диски считает чек суммы, если не ошибаюсь? почти как ZFS ...

Наверно того же эффекта можно было достигнуть на любой другой СУБД, в т.ч. на PostgreSQL,
если разместить table spaces на OpenZFS zvol + ext3/4 со включенным сжатием, например zfs set compression=lz4?

Как думаете, до какого объема бесплатный DB2 сможет нормально ворочать вашу базу без просадки производительности?

Планируете ли использовать DB2 Community в своих будущих проектах? Почему не PostgreSQL?

Про мускиль и вопросов нет :)

А что нитак с PostgreSQL? Подумываю, не заглубиться ли в его изучение ...
Но я как-то прикипел уже к DB2, от всего остального немного подташнивает.

Правда интересно, хотя бы основные причины.

Сжатие в ZFS в отличие, например, от NTFS на производительность почти не влияет, алгоритм lz4 работает почти мгновенно.
Мне кажется, что сжатие внутри СУБД может достигать большего преимущества чем ZFS только за счет большего размера блока и большего словаря по релевантным данным, но не уверен так ли это.

Сжатие в NTFS - это просто слезы, при попытке сжать например файл размером в несколько сотен гигабайт Шиндоуз "сервер" мог просто повеситься и перестать отвечать даже на RDP соединения.

Сжатие в ZFS - это то, что трудно заметить на глаз по каким-либо признакам кроме значительного экономии места на диске, для баз данных нередко в разы. Причем далеко не все СУБД поддерживают сжатие как DB2, например Firebird не поддерживает, и ZFS прекрасно решает задачу сжатия баз данных таких недоСУБД.

Вообще очень хотелось бы рассмотреть целесообразность хранения баз данных и особенно DB2 на ZFS zvol например с ext3 поверх виртуального блока. Как правильно выровнять volblocksize и размер блока ext3 и размеры критических структур данных в DB2, вероятно размер страницы для tables space. Как удачно раскидать отдельные части базы по разным zvol разных узлов(хостов) ZFS, и вероятно с использованием фич multi temperature тоже. Написал бы кто-нибудь мануальчик на Хабре?

Как бы не так:

1) Уже много лет как мощности процессора было достаточно для сжатия, кроме того нередко ZFS хранилище расположено на отдельном хосте с отдельным многоядерным CPU. В крайнем случае при высоком load average вероятно софт ZFS можно запихать в виртуалку KVM, где количество ядер больше хостового за счет распараллеливания на нитях хоста.

2) Теперь смотрим на алгоритм сжатия:
https://github.com/lz4/lz4
Он очень быстр даже для относительно медленных процессоров, всего в 2.5 раза медленнее обычного memcopy:

автор
Compressor Ratio Compression Decompression
memcpy 1.000 13700 MB/s 13700 MB/s
LZ4 default (v1.9.0) 2.101 780 MB/s 4970 MB/s
LZO 2.09 2.108 670 MB/s 860 MB/s
QuickLZ 1.5.0 2.238 575 MB/s 780 MB/s
Snappy 1.1.4 2.091 565 MB/s 1950 MB/s
Zstandard 1.4.0 -1 2.883 515 MB/s 1380 MB/s
LZF v3.6 2.073 415 MB/s 910 MB/s
zlib deflate 1.2.11 -1 2.730 100 MB/s 415 MB/s
LZ4 HC -9 (v1.9.0) 2.721 41 MB/s 4900 MB/s
zlib deflate 1.2.11 -6 3.099 36 MB/s 445 MB/s




3) IOPS HDD остались прежнеми и практически не растут последние лет 10 или больше, физически голова дисков не может рандомно елозить по поверхности быстрее, чем 200-300 раз в секунду. Поэтому операции с диском во много раз дороже, чем с процессором.

https://news.ycombinator.com/item?id=12362899

Тесты (не самые свежие):
https://www.servethehome.com/the-case-for-using-zfs-compression/

Потребление памяти у ZFS регулируется, под L1 cache можно отдать не так много и большую часть можно отдать под L2ARC, который может быть на быстром enterprise SSD, куда можно загнать почти всю базу данных.

У меня на бэкап хосте с пулом 8 ТБ на базе Core2Duo по 2 гига оперативки, из них ZFS отъедает всего 1гиг даже под нагрузкой, и это в дефолтных настройках. Для промышленного сервера 100 гиг оперативки нынче - это ничто по сравнению с преимуществами, которые можно получить.

В OpenZFS еще и persistent L2ARC появился, даже в Debian stable + backports, т.е. ваш дисковый кэш ZFS будет всегда прогрет даже после перезагрузки хранилища. А прогреть буферные пулы DB2 с 16 гигами - это минутное дело.

ZFS позволяет делать мгновенные снэпшоты, а DB2 позволяет временно на ходу заморозить записи (при этом DB2 бодро отвечает на select-ы) перед снэпшотом.

Откат на бэкап + накат логов может занимать много часов.
Рестарт базы из снэпшота можно сделать за 5-15 минут, т.е. почти мгновенно по сравнению с бэкапами.
Причем можно делать даже такие снэпшоты, на которые возможен накат архивных логов при откате назад.

Еще очень важная фишка DB2 в паре с ZFS, DB2 умеет делать бэкапы с опцией dedup, так вот такие бэкапы (в т.ч. полные) места на ZFS со включенной дедупликацией почти не занимают, только небольшой прирост, равный дельте прироста данных. Даже инкрементальные бэкапы отжирают намного больше, особенно если содержат БЛОБы.

Дедупликация OpenZFS - это конечно отдельная история, обычно пул приходится удалять раз в год для чистки, потому что стирания таких бэкапов не дождешься, но зато они и места почти не занимают и при этом по прежнему считаются полными и с любого из них можно делать rollforward.
Легко например, запихать в относительно небольшой дедуплицированный ZFS пул размером 5-10 TB полных еженедельных бэкапов террабайтной базы за целый год.

Во FreeBSD уже давно нет своей ZFS, туда втащили ZFSOnLinux :)
https://www.openzfs.org/wiki/Main_Page

авторThe OpenZFS project brings together developers from the Linux, FreeBSD, illumos, MacOS, and Windows platforms. OpenZFS is supported by a wide range of companies.

NetBSD кстати тоже :b



Это домашний бэкап сервер, очень полезный конфиг от всевозможных закладок, особенно со старыми, но большими дисками.

Я бы не доверял ценные данные современным большим серверам, дырявым как швейцарский сыр, покрытый плесенью ME подобных зондов, и современным дискам, с почти что персональным компьютером на борту каждого HDD. Что-нибудь забыть по указке сверху для них как два пальца ******.

.

Уважаемые люди не забыли нопейсать, как у них был сконфигурирован ZIL?
Я бы предпочел, чтобы они тестировали в режиме sync=disabled, потому что только в таком режиме ZFS дает производительность, близкую к режиму sync=standard при использовании для ZIL нормального оборудования типа зеркала из enterprise PCI SSD.
Этого вероятно было бы достаточно, чтобы ZFS выиграла тест.

И да, нынешняя версия ZFS работает пошустрее двухлетней давности, и постоянно идут работы по повышению производительности.

Кроме того я предлагал поверх ZFS использовать ext3/4, что нивилирует некоторые особенности файловой системы ZFS и оставляет только ее транзакционную сущность на блочном уровне.

Добавим к этому еще и то, что активные логи DB2 можно перекинуть на другой пул из чистого enterprise SSD.
А активные логи для OLTP системы - это половина нагрузки, если не больше.

И еще очень важное преимущество: ZFS позволяет снэпшотить базу DB2 на ходу, не отключая приложения в режиме write suspend.
Такого вероятно ни в PG, ни в Мусикуле нету.

По вашей же ссылке есть коментарии несогласных с "уважаемыми экспердами":

Tobias

This benchmark really is not in favour of ZFS. It‘s best practise to have a separate SSD ZFS ZIL device to have good write performance.

This benchmark is doing two disk writes for every mysql write because the data is first written to the zfs intent log snd later to the real blocks in the filesystem – sinply to have the crashsafe durable semantics of zfs. No wonder writes are 50% slower with zfs than ext4.
February 17, 2018 at 4:18 am

Yves Trudeau

I do agree with you, a SLOG would have a big impact here. Let’s say Jervin is presenting a worse case scenario and even then, considering the benefits of using ZFS, the cost is not that high. I hope he’ll present results with a decent SLOG just to size the difference. Like you said, I often got close to twice as fast for write intensive workloads with a good SLOG device.
February 19, 2018 at 10:35 am
Jervin Real

Indeed, there is not dedicated log device in this test as it is only to demonstrate how much MySQL can get slower if you simply switch your existing hardware to ZFS from another filesystem like ZFS. We will cover more cases in future blog posts.

Siemargl,

А можно посмотреть change history этого фрюшного ZFS? Он вообще развивается?
Давно ли в нем фиксили хоть один баг или вносили какое-то улучшение?

Ну не fuse же конечно же?
Думаете ядро FreeBSD будет работать с OpenZFS сильно лучше, чем Linux из-за менеджера памяти?

А что тут такого, учитывая сколько профитов дает ZFS, как минимум: проверка целостности пула, сжатие, снэпшоты, репликация.
Вы забыли отдельное SSD зеркало под активные логи базы DB2 ;)



Мне и самому интересно, но по вашей ссылке в коментариях вроде бы как раз это и обсуждаетcя?
Причем кэширование получается тройное, а не двойное, потому что у ZFS 2 уровня.
Но на втором уровне (только для чтения) можно легко зарядить кэш на быстрых SSD размером с базу или половину базы.
К примеру база размером 1TB, пул размером 5-10TB, чтобы базе легко дышалось и не чувствовалась фрагментация из-за COW.
ZFS всегда нужно добавлять нового свободного места, если остается около 80%, если нет времени на дефраг через send | receive в другой пул. Но в таком конфиге легко добавить быстрый SSD кэш на 1TB - размером с базу.
В DB2 Community с лимитом на оперативку всего 16 Гиг двойное кэширование пойдет как раз на пользу.

У меня вот идея появилась, а нельзя ли pureScale использовать с одним рабочим узлом DB2 ? :)
Это наверно даже быстрее бы работало, чем DB2 ext4 -> iSCSI -> ZFS zvol на другом хосте хранилища с большим кэшем.
Вот а если вместо это сделать так: DB2 16GB RAM working node -> pureScale CF с 100 гигами оперативки ? :)

Вернее, если занято более 80%, соответственно когда остается свободного менее 20%, особенно при высокой фрагментации.

Вот тут: https://habr.com/ru/company/tensor/blog/553754/

Копия: http://www.freezepage.com/1619463133YOOBBBMOAK

подробно расписаны недостатки PostgreSQL для тяжелых enterprise приложений.

Интересно было бы узнать, как с аналогичными фичами обстоят дела в СУБД IBM DB2, все ли хорошо по сравнению с PostgreSQL?

От себя добавлю из опыта общения с админами PostgreSQL пару лет назад, по их словам они вынуждены заниматься постоянными ежемесячными и даже чаще апгрейдами версий PostgreSQL (причем полностью вручную, по их словам автоматизировать им это не удалось, автоматических операторов у них почему-то нет или они о них не знают), потому что разработчикам их приложений постоянно хочется все более нового функционала PG. Не знаю, как на это реагировать в контексте сравнения с DB2? Возможно раньше PostgreSQL был в роли сильно отстающего и догоняющего по функционалу?

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

DB2 в последних версиях позволяет апгрейдить свой кластер master-slave вообще без downtime?