MongoDB about pisi

[examachine]

hayir baska bir db desteklemeyi su anda dusunmuyorum, zaten benim pisi icin yazdigim database sistemi mongodb kadar gelismis birsey benim kullandigim senaryo icin, python acisindan bakarsak da cok daha gelismis tabii ki. web programcilari icin gelistirilmis seyler burada faydali degil o kadar. burada system tool gelistiriyorum, onun planlamasi farkli. JSON kullaniyor olsak neyse. kullanmiyoruz. xml calisiyor, don't fix it if it's not broken.

berkeley db Oracle'in maintain ettigi birsey, bu embedded kullanim icin cok daha iyidir. onu kullanmama gerek yok o yuzden. full DBMS kullanmak fazla agir olur. NoSQL o kadar matah birsey de degil, bir ekstra guzellik saglamiyor bizim icin, xml+bdb zaten bir NoSQL yaklasimi. pisi'nin kullandigi DB facility'si ayri bir package olarak surulecek ama. autoxml de. onlar pisi'nin kendisinden daha onemli code'lar, diger turlu PISI'yi yazmak o kadar eglenceli olmayacakti zaten. bu arada o super dandik 2.x branch'inde uyduruk bir TODO var, bu autoxml'i de kaldiralim cok hairy gibi birsey yazilmis, berkeley db'yi de anlamadik biz bunu web programcilari mongodb kullaniyormus belki daha iyidir demeyelim o yuzden. hic sanmiyorum oyle olabilecegini.

SQLite'i bile kullanmadim fazla agir ve yavas olacagi icin. neden pisi bu kadar hizli saniyor insanlar acaba? cunku en hizli db implementation'ini en hizli olabilecek algoritmalari kullandim olmayanlari da kendim yazdim. C++'da yazdigim b-tree implementation'ini da kullanabilirdim ama bunda caching, transactions vs. var pisi'nin faydalandigi onlari bastan implement etmek istemedim, bu ustunde dusunulmus bir secimdi. sirf degistirmek icin degistirme gibi istekleri yapamiyorum, cok detour olur, o tur detourlar isi dagitir, zaten bu yuzden 1.1'den sonraki o abes release'leri yok saymak zorunda kaliyorum, cunku o sekilde gelisiguzel eklemeler ya da cikarmalar yapilmis, hepsini tek tek review edip duzeltmem gerek ama rationale'siz yapilmis seyler genelde, duzgun bir metodoloji izlenmemis, o yuzden ben daha onceden denedigim ve dogru oldugunu bildigim bir metodolojiye gore bir sonraki major revision'i planladim coktan. boyle bir istek icin bir rationale gerekiyor. neden?

xml processing'de birden cok xml parser destekledim cunku hangisinin sistemde olacagi belli olmaz demistik, ama yine de en hizlisini hep tercih ediyoruz. iki tane en hizli var aslinda hangisi varsa onunla calismali. burada bastan en iyisiyle baslamis olabiliriz, boyle kalsin. bunu gelistirmenin tek yolu yazdigim C++ code'u ustune bir transaction code'u yazmak olur. baska bir tur improvement olmaz. zaten berkeley db neredeyse optimal file structure'lar kullaniyor. ondan daha iyi zor yapilir yani. berkeley db'yi duzgun kullanabilmek icin de cok ugras verdik o is tamamlanacak onun yerine. Mis gibi B+-tree'si var, ama bazi optimizasyonlar yine de yapilabiliyor dogru indeks yapisi secilerek vs. Low-level calismanin bazi avantajlari var.

[poyraz76]

Bu detaylı açıklama için çok teşekkür ederim Berkeleydb terk edip leveldb geçirmiş olmaları büyük bir hata olduğu sonucuna vardım şuanda kullandığımız pisi leveldb kullanıyor çoğu zaman lock hatası alıyoruz ve bu hata leveldb sonrası çıktı diye biliyorum yanlış hatırlamıyorsam tabi leveldb geçilme sebebi lisans ile alakalıydı.

[examachine]

Lisans ile alakali olabilir ama benim hic umrumda degil o kismi, bu yeni release zaten AGPL olacak. BDB kisminda eksik olan ne varsa onun duzeltilmesi zamanin daha iyi kullanimi olur. leveldb fork'una hic bakmayacagim db tamamen degistirilebilir tabii ki ama calisan birseyi degistirmeye calismak alakasiz bir sebepten (bunun lisansini begendim) gibi bir davranis dogru degil daha onemli mevzular varken ozellikle.

Saygilar,

[examachine]

Yani Berkeley DB GPL'li software'de kullanilabiliyor, bu da GPL'le release edilmis birsey, nedir sorun anlamiyorum. AGPL'e cevirmisler, dogrusu da o, ben de AGPL kullaniyorum.

[examachine]

@poyraz76 Rica ederim biraz uzun bir aciklama oldu sacma gelmis olabilir, bununla ilgili bir coding guideline bile yazdim, bence calisan ve guvenilir bir component kullaniyorsak onu sadece yeni diye baska birseyle degistirmeye calismak genel olarak dogru degil, bir branch'de belki denenebilir, ama fazla experimental olabilir, ozellikle de soylenilen fonksiyon tam olarak tamamlanmamissa. berkeley db kullanimi daha da guzellestirilebilir, secilme sebebi embedded icin ideal bir secim olmasi. level db kullanmis arkadaslar o da olabilir ama bilmiyorum karsilastirmadim daha hizli cok olamayacagini saniyorum ama yeni bir codebase oldugu icin belki daha temiz calisiyordur onu bilemiyorum.

[examachine]

leveldb guzelmis de cok buyuk bir is yapmiyor :P transaction vs. de yok yani daha az ozelligi var bdb'ye gore. bayagi daha sinirli birsey. xml'e uyar uymasina ama bir ilerleme getirmeyebilir. bu neden degistirilmek isteniyor ki, bu keyfi birsey, ozellikle daha onemli mevzular varken.

[examachine]

yani o bence "bir degisiklik yapmis olmak icin degisiklik yapmak" sinifina giriyor, genel olarak o tur seyleri yapmiyorum.

[poyraz76]

leveldb son sürümüne baktınız mı epey bir özellik eklendi bir bakın derim.

[examachine]

baktim da hic gerek yok son derece butun bir embedded db sistemi kullaniyorken. github'da baktim etkileyici birsey degil, birisinin senior project'ini allayip pullamislar google'da basit birsey bayagi sadece tek bir file structure var. baska birsey yok. (ama simdi database'cidir doktorasini bunun ustune yapmistir o da olabilir, database camiasi bu hersey olabilir neler gorduk DB konferanslarinda :D )

[examachine]

yani uyuyor uymasina ama bdb'yi birakmak icin 0 sebep var, ne olabilir yani, butun temel file structurelari ayni sekilde calisiyor zaten farkli da degil ki standart algolar bunlar. string key, data blob. e tamam bu var zaten berkeley db'de gerek yok o yuzden. ama baska seyler de var kullandigimiz, kim leveldb daha iyi olacak sandiysa onu yanlis dusunmus.

[poyraz76]

Açıkçası benim için önemli olan iyi çalışması lisan vs hiç umursamıyorum ve diğer konular için de bu geçerli en iyi nasıl çalışır aklıma gelmişken pisi paketleri derleyip akabinde iso basacak bir yapıda olabilirse güzel olurdu ek bir yazılıma gerek duymadan derlediği paketleri iso yapabilse güzel olurdu.

[examachine]

oyle bir iki proje vardi uludag'da onlari calistirmak lazim up to date tool'larla

[poyraz76]

https://github.com/poyraz76/livecd-scripts
pisi ile çalışıyor bu düzenlenip veya örnek olarak alınıp kullanılabilir

[examachine]

teşekkürler bakalım bir de uludağ deposunda birşey var o neydi abi?

[poyraz76]

https://github.com/poyraz76/rcpisiman pardus un pisiman aracını live kurulum yapacak gale getirmiştik şuanda kullanıyoruz

[poyraz76]

https://github.com/pardus-anka/Pardusman

[poyraz76]

Pardusman ile iso hazırlanıyordu tabi bizim araç live kurulum yapabilir hale gelmiş durumda hem openrc hem müdür servis yöneticisi olarak kullanılabilir

[examachine]

Onu ayri bir bug olarak acar misin lutfen? Enhancement diyelim, boyle bir ekstra tool yazilmasi isin pisiye ne ek gerekiyor.... bu hazir olan tool'lar denensin hangisi iyi bakilsin diye yazalim.

[examachine]

CD image'i hazirlayan pardusman'dan baska bir tool da olmasi lazim ama standart pardusmana bir bakarim, live USB yapmasi lazim, CD degil.

[poyraz76]

Rcpisiman usb live yapıyor ve kurulabilir olarak hazırlıyor

[poyraz76]

yarın detaylı bir bug açarım kafamda tasarladigim ve sizece de uygun onlarsa 3 servis yönetici için de pisi iso yapabilir eğer bunu yaparsa tüm dağıtımlarda ek bir araca gerek kalmadan derleme ve iso hazırlama yapılmış olur linklerde 3 servis yönetici için hazır kodlar mevcut gözden geçirip eklenirse ciddi manada dikkat çekici olur bir diğer konu ise buildfarm zaten pisi tüm derleme işini yapıyor bu iş için de bir kaç ekleme ile ek araca gerek kalmadan kaynaktan bağımlılık sırasına göre çekip bir repo kurulabilir tabi pardus buildfarm derlenen paketleri sisteme de kuruyor ama kurmadan repo oluşturması daha iyi olur bazı paketler baselayout dbus gibi özel bir değişiklik durumunda sistemi çalışmaz hale getiriyor

[examachine]

evet ama bunlar su andaki issue'nun otesine gecen konular. onlar icin ayri enhancement issue acalim. bir iki build distro tool'u onceden yapilmis zaten bir tanesi asimile edilebilir.

bu var:

#10