Qual è l’effettivo consumo di memoria dei database, utilizzando le funzionalità della Full-Text Search (FTS)? Michal Hruby – un programmatore attivo su progetti come Zeitgeist e Synapse – ha cercato di rispondere, ripetendo il benchmark di Mathias Hasselmann con tre prodotti: Lucene++, SQLite e Xapian. I risultati fanno riflettere.

Hruby ha utilizzato la stessa distribuzione di Hasselmann, ovvero Ubuntu 12.04 (Precise Pangoline) Beta 2, con due diversi archivi di dati: uno da 17.251 e l’altro da 12.1587 record. Per la precisione, entrambi gli archivi contenevano informazioni su dei film. I picchi di memoria del benchmark premiano Lucene++, con 1,4MiB e 3.1MiB.

SQLite ha totalizzato 2,5MiB/2,6MiB, mentre Xapian 1,4Mib/5,2MiB: i risultati dei picchi non sono molto significativi e, per confermare la superiorità di Lucene++ occorre, dare un’occhiata all’intero processo. Hruby ha utilizzato Massif Visualizer di Milian Wolff, dimostrando che Xapian non mantiene una cache della prima richiesta.

Non ancora soddisfatto, Hruby ha pensato di modificare il benchmark di Hasselmann per includere una ricerca tra le wildcard in aggiunta alle richieste standard. L’intenzione era soprattutto quella di verificare le performance di Xapian, che secondo Hruby assumerebbe un comportamento inusuale. Il risultato ha confermato questa tesi.

Se Lucene++ si ferma a 4,6MiB di picco ed SQLite a 7,3Mib, Xapian raggiunge i 442,2MiB: un consumo di memoria decisamente eccessivo. Il benchmark si riferisce soltanto all’archivio più grande, utilizzando T* come wildcard — con un limite di 10.000 risultati a richiesta per ogni database. Il comportamento di Xapian è incomprensibile.

Le prove di Hruby assegnano i risultati più confortanti a Lucene++, un porting in C++ di Lucene realizzato da Alan Wright per Spotify — il popolare servizio di musica in streaming, tuttora inaccessibile dall’Italia. Sarebbe opportuno da domandarsi se molte applicazioni non gioverebbero dell’utilizzo di Lucene++, al posto di SQLite.

Via | Michal Hruby

Un test confronta le performance di FTS su Lucene++, SQLite e Xapian é stato pubblicato su Ossblog.it alle 11:00 di domenica 22 aprile 2012.

Gli sviluppatori del progetto SQLite hanno annunciato la nuova versione, 3.7.0, del loro database relazionale SQL embedded.

L’unica vera novità di questa versione è l’introduzione del Write-Ahead Log, WAL, per le transazioni. L’uso di WAL consentirà di avere prestazioni migliori, più concorrenza ed operazioni di I/O più sequenziali. Il vecchio metodo, rollback journal, è ancora il predefinito e quindi le applicazioni esistenti non avranno problemi di compatibilità.

Le altre modifiche riguardano ottimizzazioni del codice e la correzione di alcuni bug.

Via | SQLite

SQLite 3.7.0 con Write-Ahead Log é stato pubblicato su Ossblog.it alle 11:00 di venerdì 23 luglio 2010.

Oracle aveva annunciato l’ingresso nel consorzio SQLite qualche giorno fa, ma la notizia non ha suscitato clamore. Ciò si deve essenzialmente a una maggiore preoccupazione per la sorte di OpenSolaris. Eppure la scelta effettuata da Oracle di cambiare il backend di Berkeley DB ha una certa importanza. Anziché ODBC il database sfrutta ora le API di SQLite.

Il cambiamento effettivo è avvenuto col rilascio della versione 11gR2/11.2.5.0.21 di Berkeley DB. Tecnicamente il database fonde le API di SQL basate su SQLite e il sistema di memorizzazione dei dati di BDB. Un metodo che dovrebbe migliorare sensibilmente le prestazioni di Berkeley DB. Nello sviluppo sono coinvolti pure i programmatori SQL di Sun.

Oracle comprò Berkeley DB con Sleepycat Software (la società responsabile dello sviluppo del database) nel 2006. Gregory Burd, Senior Product Manager di Berkeley DB , ha confermato che «le API ANSI C di SQLite 3 sono il nuovo ODBC» e applaudito Oracle per cui non sono previsti fork del progetto originale. È prossima l’ennesima acquisizione?

Via | The H Open

Oracle è entrata nel consorzio SQLite é stato pubblicato su Ossblog.it alle 12:45 di lunedì 05 luglio 2010.

Adobe Systems ha dichiarato ufficialmente di essersi unita a Mozilla e Symbian nella sponsorizzazione del database SQLite, software pubblicamente presente in almeno due progetti di alto profilo dell’azienda: SQLite è infatti utilizzato all’interno di AIR e Photoshop Lightroom.

In cambio della loro sponsorizzazione, i membri del SQLite Consortium ottengono un vasto numero di benefici accessori, tra i quali è compresa anche “la garantita, totale attenzione degli sviluppatori di SQLite per un minimo di 23 giorni all’anno”.

Contrariamente a quello che sostiene qualcuno sembra quindi che il software a codice aperto interessi anche alle aziende.

via | CNet

Adobe entra nel SQLite Consortium é stato pubblicato su Ossblog.it alle 11:45 di mercoledì 05 marzo 2008.

La versione finale di phpBB 3 è finalmente tra noi. Dopo cinque anni di duro lavoro e ben 200.000 linee di nuovo codice il team di sviluppo ha dato alla luce una nuova incarnazione di uno tra i più noti e usati software per la creazione/gestione di forum.

Con phpBB3, nome in codice Olympus, si è fatto un deciso passo in avanti rispetto al precedente ramo 2.x includendo moltissime nuove feature come ad esempio il supporto a praticamente tutti i database più noti: MySQL, Microsoft SQL Server, Oracle, PostgreSQL, SQLite, e Firebird.

Ma novità e miglioramenti hanno riguardato anche un nuovo e più funzionale pannello di amministrazione, nuovi tool per la moderazione, BBCodes personalizzati, inclusione di allegati (immagini, documenti, video) nei post , caching delle query al database, caching dei template e molto altro come si può vedere dalla tabella comparativa con la vecchia versione.

Per chi si avvicina a questo software consiglio una lettura della QuickStart Guide e della documentazione in italiano, apparsa sul forum di phpbb.it, su come installare la nuova release e aggiornare phpBB2 a phpBB3.

Download: phpBB 3.0.0

[Via | nixcraft]

phpBB 3.0.0 è arrivato é stato pubblicato su Ossblog.it alle 02:05 di venerdì 14 dicembre 2007.

Come abbiamo visto qualche giorno fa è stato rilasciato da poco un nuovo desktop search engine per linux chiamato GLS e basato sull’accoppiata Lucene/Posgres, ci è stato fatto notare che in realtà questa soluzione non è l’unica attualmente disponibile per il nostro pinguino e ci è stato chiesto di parlare anche delle altre possibili alternative.

Già da un paio di anni è presente Beagle, applicazione scritta in Mono che usa al suo interno sempre Lucene ma con SQLite, di cui abbiamo già parlato abbondantemente visto che è strettamente integrata con Gnome (nonostante si professi Desktop Environment agnostic).

Proprio l’integrazione con Gnome è uno dei maggiori punti di forza di Beagle, infatti scrivere dei plugin per far indicizzare i dati delle proprie applicazioni è molto semplice e già sono molti i software che lo integrano nativamente, dato che è preinstallato in distribuzioni come Fedora e SuSE (gli utenti Ubuntu lo hanno disponibile all’interno dei repository Universe).

La stessa Novell (azienda che ha fatto nascere e finanziato il progetto) ha integrato Beagle all’interno dell’edizione Enterprise di SuSe comprendendone le potenzialità.

Purtroppo Beagle è, allo stato attuale, una applicazione mangia-risorse senza pietà. Anche a causa di un motore, Lucene, non adatto a questo genere di applicazioni (imho è uno dei computazionalmente peggiori desktop search engine sul mercato OSS).

Un altro progetto, nato in seno all’iniziativa FreeDesktop.org ed ospitato su CVS di Gnome è Tracker.

A differenza degli altri due software già visti non usa Lucene ma ha al suo interno una versione riveduta e corretta di MySQL ottimizzata per occupare solo 1Mb di RAM in fase di esecuzione. Tracker, essendo scritto in C e basato interamente su un DBMS, sfrutta strumenti come il full-text indexing nativamente ed in parallelo su più processi senza sovraccaricare eccessivamente le nostre povere CPU. Tra l’altro Tracker implementa al suo interno la gestione dei Metadati introdotta da FreeDesktop e che sarà parte integrante delle prossime versioni dei maggiori Desktop Environment.

Purtroppo i plugin per questo search engine sono ancora molto pochi ed a parte i file presenti su filesystem non è possibile indicizzare altro (in realtime). Questo però non dovrebbe essere un grosso problema a lungo termine, anche perchè facendo appunto parte di FreeDesktop potrà avvalersi di DBUS per comunicare con le altre applicazioni permettendo quindi una più semplice integrazione sia con Gnome (di cui già sfrutta la Deskbar applet) che con KDE.

Linux ed il desktop search engine é stato pubblicato su Ossblog.it alle 13:07 di mercoledì 12 luglio 2006.