Software-update: MariaDB 10.5.1

MariaDB is ontstaan als fork van MySQL, nadat dit in 2009-2010 door Oracle werd overgenomen. Voor een overzicht van de verschillen tussen MariaDB en MySQL kun je op deze en deze pagina's terecht. MariaDB is een krachtige opensourcedatabaseserver, die vooral populair is als website- en forumdatabase. De ontwikkelaars hebben versie 10.5.1 uitgebracht als bèta. De beknopte aankondiging van deze uitgave ziet er als volgt uit:

MariaDB 10.5.1 Release Notes

MariaDB 10.5 is the current development series of MariaDB. It is an evolution of MariaDB 10.4 with several entirely new features not found anywhere else and with backported and reimplemented features from MySQL. MariaDB 10.5.1 is a Beta release. Thanks, and enjoy MariaDB!

Notable Changes

InnoDB

• Remove dummy tablespace for the redo log (MDEV-18115)
• Optimize access to InnoDB page header fields (MDEV-21133)
• Remove multiple InnoDB buffer pool instances (MDEV-15058)
  • Deprecate and ignore innodb_buffer_pool_instances and innodb_page_cleaners
  • Columns that indicated the buffer pool instance from the Information Schema innodb_buffer_page, innodb_buffer_page_lru, innodb_buffer_pool_stats, innodb_cmpmem and innodb_cmpmem_reset tables now return a dummy value of 0.
• Deprecate and ignore innodb_log_optimize_ddl (MDEV-19747)
• Prefer MDL to dict_sys.latch for innodb background tasks (MDEV-16678)
• Use fdatasync() for redo log where appropriate (MDEV-21382)
• Replace recv_sys.heap with list of buf_block_t (MDEV-21351)
• Several fixes to server hangs (MDEV-16264)

Optimizer

• Allow packed values of non-sorted fields in the sort buffer (MDEV-21263)

Replication and Galera

• slave_parallel_mode now defaults to optimistic (MDEV-18648).
• Make REPLICA a synonym for SLAVE in SQL statements (MDEV-20601)
• Galera GTID support (commit)
• Add new mode to wsrep_OSU_method in which Galera checks storage engine of the effected table (MDEV-20051)
• Galera: Replicate MariaDB GTID to other nodes in the cluster (MDEV-20720)

PCRE

• Migrate to PCRE2 (MDEV-14024)

Compatibility

• Port show_old_temporals from MySQL 5.6 (MDEV-19906)

Variables

• Numerous deprecated variables removed (MDEV-18650)
  • multi_range_count
  • thread_concurrency
  • timed_mutexes

Versienummer	10.5.1
Releasestatus	Beta
Besturingssystemen	Windows 7, Linux, BSD, macOS, Solaris, UNIX, Windows Server 2008, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016
Website	MariaDB
Download	https://downloads.mariadb.org/mariadb/10.5.1
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (10)

Er zijn echt mooi wat voordelen om MariaDB te gebruiken. MySQL gebruiken wij bijna niet meer (Oracle bah).

Maar je ziet dat beide nu wel hun eigen weg een beetje gaan. Dat is is wel iets om rekening mee te houden! Zo heeft MySQL native support voor JSON in je queries. En MariaDB heeft dat dus niet. Wel met een begrijplijke reden: Dit is niet volgens de SQL standaarden.

Mariadb 10.2 heeft ondersteuning voor json of het hetzelfde is als wat jij bedoelt weet ik echter niet:
https://mariadb.com/database-topics/semi-structured-data/

Nee dat is niet het zelfde :-)

@mimic . Bij MariaDB kan het ook wel, alleen het is anders (zie comment @Tazzios ) . Ik persoonlijk vind dit veel duidelijker dan:
https://www.mysqltutorial.org/mysql-json/

[Reactie gewijzigd door johnny2000 op 24 februari 2020 13:10]

Hoewel ik het er mee eens ben, zou dit prima in een plugin gerealiseerd kunnen worden. JSON in een query klinkt wel aantrekkelijk.

Je kunt die JSON prima opslaan in een LONGTEXT veld zoals MariaDB dat doet en door de applicatie zelf vervolgens laten afhandelen, zoals Laravel bijvoorbeeld dat ook ondersteund.

Toegeven dat native waarschijnlijk sneller is, maar als je alles in JSON wilt doen zijn daar ook andere oplossingen voor zoals mongo.

Bij MySQL zitten ze uiteraard ook niet stil.

Als je niet om MySQL heen kunt is MariaDB een goeie implementatie, maar als je echt iets te kiezen hebt, zoals in een greenfield project, dan ben je vaak toch beter af zonder MySQL of diens afstammelingen. PostgreSQL is op de meeste vlakken heel wat stappen vooruit op MySQL.

Hangt er vanaf, als je een eenvoudige SQL database nodig hebt ben je met MySQL in sommige gevallen beter af. Met name het geval als je veel connecties moet afhandelen: PostgreSQL start een nieuw proces per connectie (met het nodige geheugengebruik van dien).

Voor complexere databases, overloaden van functies etc. ben je inderdaad beter af met PostgreSQL!

Hoeveel connecties heb je nodig dan? Volgens mij implementeren de meeste applicaties toch iets van connection pooling, aangezien het opbouwen van een connectie nogal traag kan zijn?

Bij "standaard" applicaties niet veel. Er zijn echter situaties waar het snel op kan lopen, bv. bij applicaties welke per client in een container draaien. Heb je weliswaar nog steeds persistent connecties, maar de pool is per instance / client.