автор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. Что-нибудь забыть по указке сверху для них как два пальца ******.