Software-update: Sqlite 3.6.6.2

Sqlite is een in c ontwikkeld databasesysteem dat als database voor onder meer websites en embedded applicaties te gebruiken is. Volgens de ontwikkelaars heeft Sqlite geen installatie en administratie nodig, ondersteunt het databases tot een omvang van twee terabyte en wordt een volledige database opgeslagen in één bestand. Verder ondersteunt het bijna de volledige Sql92-specificatie en is het eenvoudig aan te sturen via onder andere Tcl/Tk. De ontwikkelaar heeft enkele dagen geleden versie 3.6.6.2 met de volgende lijst van aanpassingen de deur uitgedaan:

Version 3.6.6.2:

• Fix a bug in the b-tree delete algorithm that seems like it might be able to cause database corruption. The bug was first introduced in version 3.6.6 by check-in [5899] on 2008-11-13.
• Fix a memory leak that can occur following a disk I/O error.

Version 3.6.6.1:

• Fix a bug in the page cache that can lead database corruption following a rollback. This bug was first introduced in version 3.6.4.
• Two other very minor bug fixes

Version 3.6.6:

• Fix a #define that prevented memsys5 from compiling
• Fix a problem in the virtual table commit mechanism that was causing a crash in FTS3. Ticket #3497.
• Add the application-defined page cache
• Added built-in support for VxWorks

Version 3.6.5:

• Add the MEMORY option to the journal_mode pragma.
• Added the sqlite3_db_mutex() interface.
• Added the SQLITE_OMIT_TRUNCATE_OPTIMIZATION compile-time option.
• Fixed the truncate optimization so that sqlite3_changes() and sqlite3_total_changes() interfaces and the count_changes pragma return the correct values.
• Added the sqlite3_extended_errcode() interface.
• The COMMIT command now succeeds even if there are pending queries. It returns SQLITE_BUSY if there are pending incremental BLOB I/O requests.
• The error code is changed to SQLITE_BUSY (instead of SQLITE_ERROR) when an attempt is made to ROLLBACK while one or more queries are still pending.
• Drop all support for the experimental memory allocators memsys4 and memsys6.
• Added the SQLITE_ZERO_MALLOC compile-time option.

Versienummer	3.6.6.2
Releasestatus	Final
Besturingssystemen	Windows 9x, Windows NT, Windows 2000, Linux, BSD, Windows XP, DOS, macOS, Solaris, UNIX, Windows Server 2003, Windows Vista, Windows Server 2008
Website	Sqlite
Download	http://www.sqlite.org/download.html
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (10)

[Johnny]

SQLite is geen alternatief voor echte databaseservers die via een netwerk meerdere gebruikers bedienen, het is bedoeld om lokaal door een enkele gebruiker te worden gebruikt als vervanging voor allerlei binaire opslagformaten of wazige dingen zoals "XML-databases" die programma's soms gebruiken om gegevens op te slaan.

De performance er van is vergelijken met de andere opties vrij goed, maar je kan het niet vergelijken met een echte databaseserver die altijd bereikbaar is. Een SQLite-database zal namelijk vanaf je eigen harde schijf moeten worden geopend wat de snelheid niet ten goede komt.

[PV85]

Om maar even het bovenstaande wat in perspectief te plaatsen, het ligt een beetje in het midden:

Websites

SQLite usually will work great as the database engine for low to medium traffic websites (which is to say, 99.9% of all websites). The amount of web traffic that SQLite can handle depends, of course, on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.



Client/Server Applications

If you have many client programs accessing a common database over a network, you should consider using a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, the file locking logic of many network filesystems implementation contains bugs (on both Unix and Windows). If file locking does not work like it should, it might be possible for two or more client programs to modify the same part of the same database at the same time, resulting in database corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.

A good rule of thumb is that you should avoid using SQLite in situations where the same database will be accessed simultaneously from many computers over a network filesystem.

[Reactie gewijzigd door PV85 op 24 juli 2024 19:23]

[phobosdeimos]

Laten we even enkele fouten die je hier maakt rechtzetten.
Een sqlite database kan net zo goed dienen om honderden gebruikers te bedienen. Ik gebruik sqlite regelmatig in web applicaties met tientallen gelijktijdige gebruikers.
Daarnaast hoeft een sqlite db niet per sé op "je eigen harde schijf" te leven. De meeste van mijn sqlite db's leven op 15.000 RPM SAS schijven in krachtige servers.
Af en toe plaats ik de volledige database in het ram geheugen, wat 100x sneller is dan mysql/postgresql/wat dan ook.

Best geen opmerkingen geven over onderwerpen waarvan je duidelijk weinig afweet.

[Verwijderd]

Ik denk dat Johnny bedoeld dat SQLite de -gehele- database (file) locked wanneer er INSERT of UPDATE statements plaats vinden (SQLITE_BUSY). Dit is niet bepaald gedrag dat geschikt is voor honderden gebruikers. Als je voornamelijk SELECT statements uitvoert, dan kan SQLITE wel geschikt zijn. Verder, als je SQLite database in-memory werkt en de stroom valt uit (of je OS crashed), dan zijn je database gegevens weg.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 19:23]

[PV85]

Voor een simpele website op basis van een CMS is het heel handig om in productie je DB in het geheugen te laden.

[Little Penguin]

Een SQLite-database zal namelijk vanaf je eigen harde schijf moeten worden geopend wat de snelheid niet ten goede komt.

Deze beperking geldt echter ook voor iedere andere database -tenzij je een 100% memorized db gebruikt. Ook een client/server RDBMS -zoals Oracle of DB2- zal regelmatig de gegevens van disk moeten halen.

Voor embedded werk is SQLite echter uitstekend geschikt, met een omvang van zo'n 300KiB kun je de engine zo'n beetje overal gebruiken...

[phobosdeimos]

sqlite is een van de snelste database implementaties, helemaal als je diverse optimalisaties aanzet die alle operaties in-memory doen (met een iets groter risico op data-loss).
Als je een eenvoudige database hebt, waar performance belangrijker is dan de data op zich, is sqlite echt een aanrader.

[Verwijderd]

Wat zijn de ervaringen mbt SQLite performance? Hoe verhoudt de performance zich tot Sql Server met betrekking tot het invoegen van rijen ( insert ) en grote hoeveelheid rijen ophalen ( select )?

[bastv]

http://www.sqlite.org/speed.html

[Little Penguin]

Ik vind zelf dat SQLite best wel snel is, maar dat kan ook komen omdat ik betrekkelijk weinig data verwerk. Als je echter bedenkt dat SQLite ook in Mozilla gebruikt wordt voor o.a. de geschiedenis en de bladwijzers dan denk ik dat dit genoeg aangeeft voor de snelheid van de engine.

Je kunt SQLite echter niet vergelijken met een full-feature database, zoals o.a. Oracle en Mssqlserver. SQLite is vooral bedoeld te gebruiken als en embedded database, terwijl Oracle e.d. bedoeld zijn voor productie-servers - de hoeveelheid data die je verwerkt is geheel anders bij een volledige database als Oracle of DB2.