{"id":106417,"date":"2023-01-19T18:48:11","date_gmt":"2023-01-19T16:48:11","guid":{"rendered":"https:\/\/prohoster.info\/?p=106417"},"modified":"2023-01-24T13:52:43","modified_gmt":"2023-01-24T11:52:43","slug":"razrabotchiki-sqlite-razvivayut-bekend-hc-tree-s-podderzhkoj-parallelnyh-operaczij-zapisi","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/razrabotchiki-sqlite-razvivayut-bekend-hc-tree-s-podderzhkoj-parallelnyh-operaczij-zapisi","title":{"rendered":"Die SQLite-Entwickler entwickeln den Backend HC-tree mit Unterst\u00fctzung f\u00fcr parallele Schreiboperationen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Entwickler des SQLite-Projekts haben mit dem Testen des experimentellen Backends HCtree begonnen, das eine Zeilen- (row) Sperrung unterst\u00fctzt und ein hohes Ma\u00df an Parallelit\u00e4t bei der Verarbeitung von Anfragen erm\u00f6glicht. Das neue Backend zielt darauf ab, die Effizienz der Nutzung von SQLite in Client-Server-Systemen zu erh\u00f6hen, in denen eine gro\u00dfe Anzahl gleichzeitiger Schreibanfragen an die Datenbank bearbeitet werden muss. <\/p>\n
Die urspr\u00fcnglich in SQLite verwendeten b-tree-Strukturen sind nicht auf diese Art von Belastung ausgelegt, was SQLite die M\u00f6glichkeit der Aufzeichnung nur in einem Threads einschr\u00e4nkt. Als Experiment begannen die Entwickler, eine alternative L\u00f6sung zu entwickeln, die die HC-tree-Strukturen zur Speicherung verwendet und besser f\u00fcr die Parallelisierung von Schreiboperationen geeignet ist. <\/p>\n
Um die gleichzeitige Ausf\u00fchrung mehrerer Schreiboperationen in HCtree zu organisieren, wird ein Mechanismus zur Transaktionsaufl\u00f6sung verwendet, der Seitenlevel-Blockierungen anwendet und dem MVCC (Multi-Version Concurrency Control) \u00e4hnlich ist, aber Transaktionspr\u00fcfungen basierend auf Schl\u00fcsseln und Schl\u00fcsselbereichen anstelle von Seiten-Sets verwendet. Lese- und Schreiboperationen werden im Zusammenhang mit einem Snapshot der Datenbank ausgef\u00fchrt, dessen \u00c4nderungen in der Hauptdatenbank erst nach dem Abschluss der Transaktion sichtbar werden. <\/p>\n
Clients k\u00f6nnen drei Arten von Transaktions\u00f6ffnungen verwenden: <\/p>\n
\n
\u00abBEGIN\u00bb \u2014 Transaktionen ber\u00fccksichtigen keine Zugriffs-Informationen anderer Clients. Wenn innerhalb einer Transaktion Schreiboperationen ausgef\u00fchrt werden, kann die Transaktion nur dann festgeschrieben werden, wenn in der Zeit ihrer Ausf\u00fchrung keine anderen Schreiboperationen in der DB stattgefunden haben.\n
\u00abBEGIN CONCURRENT\u00bb \u2014 Transaktionen sammeln Informationen \u00fcber den Zugriff anderer Clients. Wenn innerhalb einer Transaktion Schreiboperationen ausgef\u00fchrt werden, kann die Transaktion festgeschrieben werden, wenn seit der Erstellung des Snapshots in der DB andere Transaktionen festgeschrieben wurden.\n
\u00abBEGIN EXCLUSIVE\u00bb \u2014 Nach Er\u00f6ffnung der Transaktion sperrt diese Operationen von anderen Transaktionen bis zu ihrem Abschluss. <\/ul>\n
HCtree unterst\u00fctzt die Master-Slave-Replikation, die es erlaubt, Transaktionen in eine andere DB zu \u00fcbertragen und sekund\u00e4re DBs synchron mit der Haupt-DB zu halten. HCtree beseitigt auch die Beschr\u00e4nkung hinsichtlich der Gr\u00f6\u00dfe der DB \u2014 anstelle von 32-Bit-Datenseiten-IDs werden in HCtree 48-Bit-IDs verwendet, was die maximale Gr\u00f6\u00dfe der DB von 16 Tebibyte auf 1 Exbibyte (eine Million Tebibyte) erh\u00f6ht. Es wird erwartet, dass die Leistung von SQLite mit dem HCtree-Backend nicht geringer ist als die eines klassischen, einstufigen Backends. SQLite-Clients mit Unterst\u00fctzung f\u00fcr HCtree k\u00f6nnen sowohl auf DBs basierend auf der HC-tree-Struktur als auch auf alte SQLite-DBs zugreifen. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"