Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 10 reacties
Bron: Sqlite

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.)
Moderatie-faq Wijzig weergave

Reacties (10)

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.
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 3 december 2008 20:52]

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.
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 tigger op 3 december 2008 21:52]

Voor een simpele website op basis van een CMS is het heel handig om in productie je DB in het geheugen te laden.
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...
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. :Y)
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 )?
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.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True