Absürt Başarı
(marginalia.nu)- Marginalia Search, son değişikliklerle RAM gereksinimini yarıya düşürdü ve yükseltmeler sırasında arama motorunu kapatmak zorunda kalmanın getirdiği operasyonel yükü büyük ölçüde azalttı
- Kesinti, en son sürümden sonra indeks geçişi sırasında ortaya çıktı; yükseltme sırasında URL veritabanını silen yapı uzun süre çevrimdışı kalmaya yol açtı
- URL deposu, devasa MariaDB tabloları ve indeksleri merkezli yapıdan tek bir SQLite veritabanına ve süreç tarafından üretilen 64 bit URL ID yapısına geçti
- Ters indeks üretimi, yoğun term ID’leri için kullanılan lexicon’dan ve büyük ölçekli rastgele yazmalardan vazgeçip küçük preindex’ler oluşturduktan sonra bunları birleştiren bir yönteme dönüştü
- Yeni yapı, kötü bir dağıtımda bile birkaç saat içinde kurtarılabilecek dosya yedeklerini mümkün kılıyor ve Wikipedia gibi çok değişmeyen büyük veri işleme sonuçlarının yeniden kullanımını kolaylaştırıyor
Arama motorunun operasyon koşulları bir haftada nasıl değişti
- Marginalia Search, bir haftalık kodlamayla uzun süredir devam eden birden fazla sorunu aynı anda azalttı
- Arama motorunun RAM gereksinimi yarıya indi
- Yükseltme sırasında sistemi çevrimdışına alma ihtiyacı ortadan kalktı
- İndekslenebilir belge sayısındaki katı sınır kaldırıldı
- Korpusa dahil edilebilecek anahtar kelime sayısındaki yumuşak sınır 4 kat arttı
- Sistemi düşük performanslı donanımlarda da çalıştırılabilir tutmak uzun vadeli hedefti; bu değişiklik, 32 GB RAM’li geliştirme makinesini rahat hissettiren önceki iyileştirmeden bile daha büyük bir ilerleme
Kesintiyi büyüten eski yükseltme yapısı
- Marginalia Search, en son sürümdeki sorun nedeniyle neredeyse bir hafta çevrimdışı kaldı
- Doğrudan neden, görece küçük ölçeklenebilirlik sorunlarının zincirleme etkisiydi; ancak normalde 1 gün, sorun olduğunda 2-3 gün süren bir sürecin birkaç kez yeniden başlatılması gerekti
- Yeniden başlatmaların çoğu RAM yetersizliği nedeniyle yaşandı
- Kesintinin kullanıcılara bu kadar belirgin görünmesinin nedeni, indeks geçişi sırasında sistemin çevrimdışına alınmak zorunda kalmasıydı
- Eski yapıda yükseltme sırasında URL veritabanı siliniyordu; 1 milyara yakın satırlı bir tabloya hızlıca satır eklemek ve güncellemek darboğaz haline geliyordu
- Yeni verileri yükleyen süreç çok fazla RAM kullanıyordu
- Aynı şekilde RAM kullanan indeks servisiyle eşzamanlı çalıştırılması zordu
- Birincil anahtar 32 bit tamsayı olduğundan 2 milyarı aşmakta zorlanan bir sınır vardı
URL veritabanının yeniden tasarlanması
- URL veritabanı, arama motorunun eski bileşenlerinden biriydi ve ilk tasarım kararları artık mevcut sistem yapısıyla uyumsuz hale gelmişti
- Merkezinde, yalnızca yeni indeks yüklenirken kullanılan ve yalnızca birincil anahtar aramalarıyla okunan iki tablo vardı
- URL tablosu her URL’ye benzersiz bir sayısal ID atıyordu
- PAGE_DATA tablosu indekslenen bağlantının başlığı ve açıklaması gibi bilgileri içeriyordu
- Alan adı içindeki yol benzersizliğini koruyan ek bir indeks vardı; ancak üstlendiği role kıyasla çok büyüktü
- Yeni yapı, iki tabloyu tek tabloluk bir SQLite veritabanında birleştiriyor; loader süreci benzersiz ID üretimini üstleniyor ve indekslenmeyen URL listesi ayrı bir tabloyla ele alınıyor
- MariaDB ile SQLite’ı birlikte kullanmak geleneksel bir tercih değil; ancak iki depo farklı ihtiyaçları karşılıyor
- Sistem görece küçük, kalıcı bir dünya görüşüne ihtiyaç duyuyor
- Aynı zamanda terabayt ölçeğindeki durumun tak-çalıştır gibi değiştirilebilmesi gerekiyor
- DOCUMENT ve DOMAIN tabloları veritabanları arasında gevşek biçimde ilişkili olsa da gerçek bir join gerekmiyor
- Felaket durumunda DOMAIN tablosunun önemli bölümleri DOCUMENT tablosundan yeniden oluşturulabilir
İndekssiz 64 bit URL ID üretmek
- Eski URL tablosu 32 bit ID kullanıyordu ve tamsayı taşmasına yaklaşmış olması bilinen bir ölçeklenebilirlik sorunuydu
- URL veritabanının silinme nedenlerinden biri de ID sütununun taşmasını önlemekti
- Basit bir sayaç tek başına tekrar eden URL’leri işleyemez; görülmüş tüm URL koleksiyonunu bellekte tutma yaklaşımından da kaçınmak gerekiyordu
- Yeni yöntem, ID’yi veritabanının atamasına bırakmak yerine 64 bit ID’yi doğrudan oluşturuyor
- Alt 26 bit sıra numarası olarak kullanılıyor
- 26–56. bitler belge ID’si olarak kullanılıyor
- En üst bitler indeks sıralama hilesi için ayrılıyor
- Bu yerleşim, alan adı başına yaklaşık 67 milyon belgeye izin veriyor
- Bu, İngilizce Wikipedia’nın yaklaşık 10 katı büyüklükte
- 2 milyara kadar alan adına izin veriyor
- Marginalia’nın web’in herhangi bir yerinde referansını gördüğü alan adı sayısının neredeyse 100 katı
- Veri tutarlılığı sorumluluğu veritabanından veri üretim sürecine geçiyor; ancak bunu orada zorlamanın maliyeti çok daha düşük
URL yeniden tasarımının azalttığı bellek yükü
- Devasa indeksler ile sıcak ve soğuk URL verilerini karıştıran büyük tablonun kaldırılmasıyla MariaDB sunucusunun artık 36 GB RAM’e ihtiyacı kalmıyor
- MariaDB’de kalan sıcak veri en fazla birkaç yüz MB düzeyinde; sunucuya ayrılması gereken RAM’in de 2 GB’tan fazla olması muhtemelen gerekmiyor
- SQLite verileri de birincil anahtar için indekse ihtiyaç duyuyor; ancak gerçekten sıcak indeks bölümünün 1 GB’ın altında olması bekleniyor
- İndekslenen veri miktarı tek haneli bir ölçeğe düşüyor
- İndeks hedefi tek bir 64 bit long
- Ek benzersizlik kısıtı yok
- Loader çıktısının bir dosya demetine dönüşmesi otomatik yedek oluşturmayı kolaylaştırıyor
- Kötü bir dağıtım yaşansa bile eskisi gibi neredeyse bir hafta değil, birkaç saat içinde kurtarma mümkün
Ters indeks üretimindeki darboğaz
- Loader, URL veritabanını ve belge merkezli
(document, words[])journal’ını üretir; arama için bunun(word, documents[])biçimine çevrilmiş bir indeksine ihtiyaç vardır - Eski yöntem, anahtar kelime dizelerini yoğun term ID’lerine eşleyen bir lexicon kullanıyordu
- İlk kelime ID 0’ı, sonraki kelime ID 1’i alacak şekilde çalışıyordu
- Dizeler 64 bit hash ile long’a eşleniyordu
- Yapı fiilen long-to-int türünde bir açık hashmap’ti
- Bu yapı ölçek büyüdükçe kolayca doluyor
- Java, 2 milyardan fazla eleman içeren dizilere izin vermiyor
- Kullanılan implementasyon daha 1 milyar düzeyinde tıkanıyor
- 1 milyar entry’de 12 GB RAM kullanıyor
- Çalışan index service 60 GB RAM kullanıyor ve bunun çoğu off-heap bellek
- On-heap boyutunun 32 GB’ı aşması nedeniyle CompressedOOPs kullanmanın zorlaşması da bir sorundu
Eski ters indeks algoritmasının yazma çoğalması
- Eski algoritma en büyük word ID’yi buluyor, o boyutta bir counts dizisi oluşturuyor, ardından kelime başına belge konumlarını hesaplayıp belge verilerini memory-mapped dosyaya yazıyordu
- Bu yöntem, word ID alanının yoğun biçimde dolu olduğu varsayımı nedeniyle lexicon’a ihtiyaç duyuyordu
- Daha büyük darboğaz, yaklaşık 1 TB veriyi neredeyse tamamen rastgele sırayla memory-mapped dosyaya yazma süreciydi
- SSD’ler okumada rastgele erişimi iyi yönetir; ancak küçük yazmalarda write amplification (yazma çoğalması) sorunu oluşur
- SSD, diskteki tek bir baytı güncellerken bile tüm sayfayı silip yeniden yazmak zorundadır
- Bitişik yazmaları birleştiren önbellekler vardır; fakat terabayt ölçeğinde rastgele yazmalarda etkili olmazlar
- 1 TB yazılırken sürücü yaklaşık 0,5 PB yazmış duruma gelir
- Geçici hafifletme olarak
RandomWriteFunnelvardı- Yazmaları önce küçük dosya bucket’larına ayırıyordu
- Ardından büyük dosyayı sıralı biçimde yazıyordu
- Özgün yöntemden daha iyiydi ama yine de çok yavaştı
Küçük preindex oluşturup birleştirmek
- Yeni ters indeks üretimi, tüm verinin belleğe sığdığı küçük indekslerden birkaç tane oluşturup sonra bunları birleştirme yöntemini kullanıyor
- Sıralı listeleri birleştirmek hızlıdır ve mekanik sabit diskler için de uygun bir işlemdir
- Bu yöntemde lexicon’a ihtiyaç kalmıyor
- 64 bit dize hash’i doğrudan term ID olarak kullanılabiliyor
- Başlangıçta ortaya çıkan sorun, girdinin sıkıştırılmış olması ve indeks birleştirme yöntemiydi
- Sıkıştırılmış girdinin bir kısmını hızlıca okumak yerine, birden fazla küçük dosya oluşturup tek tek okuyor
- İndeksi oluşturduktan sonra birleştirmek yerine, veriyi indeks oluşturmadan önce birleştiriyor
- Yeni soyutlama olan
preindex, kelime ID dizisi, count dizisi ve belge verisi dizisinden oluşuyor - Girdi küçük olduğu için preindex’lerin çoğu RAM’de oluşturulabiliyor; oluşturulurken diske commit ediliyor ve sonraki birleştirme aşamasında nihai preindex ortaya çıkarılıyor
- Nihai preindex, eskisi gibi words tablosuna ve her document block’a statik btree indeksi eklenerek ters indekse dönüştürülüyor; bu süreç görece hızlı
Operasyon ve veri yeniden kullanımında ortaya çıkan değişiklikler
- Lexicon’ın kaldırılması RAM gereksinimini düşürdü; yeni ters indeks üretimi de eski algoritmadan daha hızlı
- Eski lexicon, işlenen her veri demeti için ayrı bir lehçe oluşturuyordu
- Aynı kelime bir çalıştırmada bir ID, başka bir çalıştırmada başka bir ID alabiliyordu
- Bu yüzden tüm verilerin aynı anda işlenmesi gerekiyordu
- Lexicon’dan vazgeçilmesiyle farklı veri demetlerini birleştirmek mümkün hale geldi
- Wikipedia gibi büyük ve nadiren değişen verilerin işleme sonuçları yeniden kullanılabiliyor ve daha sık değişen indeks verileriyle birleştirilebiliyor
- Bu değişiklik, bilinen ölçeklenebilirlik sorunlarının ve operasyonel rahatsızlıkların neredeyse tamamını azalttı; daha fazla yan etkiyi değerlendirebilecek bir durum yarattı
2 yorum
Marginalia - bağımsız olarak işletilen DIY arama motoru
Hacker News yorumları
Dünyanın geri kalanının tam ters yönüne giden bir projede böyle başarı örnekleri görmek gerçekten insanı mutlu ediyor
Buna Engildification demek istiyorum; böyle şeylerin daha çok olması gerek
Sleeping At Night yazısını da beğenmiştim; yakın zamandaki “Lie Still in Bed” yazısıyla birlikte, uyku eğitimi sorununu düzeltmek için çok basit bir seçenek gibi görünüyor
Marginalia arama motorunun yazarı yakın zamanda tam zamanlı çalışmaya geçti ve bildiğim kadarıyla ekip büyüklüğü 1 kişi; bu yüzden enshittification riskinden en uzak noktada. Asıl böyle ölçekte mücevherler ortaya çıkıyor; yaratıcılık, özgünlük ve vizyon parlıyor
Bu yorum, “masa başı işi bırakıp bağımsız çalışalım” topluluğu tarafından desteklenmiştir
Kaynak tüketimini yarıya indirdi, daha küçük ekranda eskisinden daha üretken oldu ve geceleri kütük gibi derin uyuyor
İlgilenenler için bağlantı: https://www.marginalia.nu/log/86-sleep/
Bu arada, Hacker News’te de görmüş olabileceğiniz ücretli arama motoru Kagi, Marginalia’yı veri kaynaklarından biri olarak kullanıyor
https://help.kagi.com/kagi/search-details/search-sources.htm...
“non-commercial” lensini kullanırsanız, Kagi’nin kendi dizini ve bazı bağımsız kaynaklardan gelen sonuçlarla birlikte bu tür sonuçlara öncelik veriliyor
Bu yazıyı görünce, insanın yapay kısıtlamalar olmadan üstün şeyler üretmesi zor bir varlık olabileceğini düşünüyorum
Marginalia’nın saçma derecede verimli olmasının nedeni, Victor’ın çalıştırma donanımını ve bellek kapasitesini bilinçli olarak sınırlaması
Sadece 32GiB daha ekleseniz bir süre idare ederdi, ama verimsiz tasarım kalırdı; ileride daha karmaşık hale gelmişken aynı sorun patlayıp düzeltilmesi zorlaşabilirdi
Bu varsayım doğruysa, günümüz yazılımlarının neden şişkin, yavaş ve bol hatalı olduğunu da açıklar. Tek tek yazılımlar bağımsız olarak sınıra pek yaklaşmadığı için, her parça verimsiz olsa bile modern M2 Pro’lar ve GiB düzeyinde bağlantılarla sorun noktasının sürekli önüne geçiliyor
Sonuç, kişinin kendini sınırlamasının uzun vadede hem kendisi hem de herkes için daha iyi olabileceği yönünde olabilir
Birçok uygulamada küçük optimizasyonlara bu kadar çok zaman harcamak mantıklı değil. Bir sunucuya 50 doların altında 32GiB RAM ekleyebiliyorken, bunu saatlik en az 20 dolardan 40 saatten fazla geliştirici zamanı harcamakla karşılaştırınca iş açısından cevap belli. Üstelik web sitesi bir hafta boyunca kapalı kalmış; bu tek başına çoğu işi öldürebilir
Teknik insanlar böyle derin kazıları sever; önemsiz kodları bile yıllarca mikro-optimize etmek isterler, ama bitmek bilmeyen yak tıraşlamayla para kazanılmaz. Kod yalnızca çok az sayıda makinede çalışıyorsa genelde buna değmez. Bu tür optimizasyonlar çoğu zaman bakımı daha zor kodla da sonuçlanır
Bugün kullanıcı cihazlarında çalışan uygulamalardaki yazılım şişkinliğinin büyük ölçüde geliştirici cihazlarıyla kullanıcı cihazları arasındaki uyumsuzluktan geldiğini düşünüyorum. Geliştiricinin işini yapmak için yüksek performanslı bir iş istasyonuna ihtiyacı var ve temel testleri de onunla yapıyor; kullanıcı ise 5 yıl önce bile orta-alt sınıf olan bir cihazda çalıştırıyor
Bir yöneticiye “150MB bellek tasarrufu sağlayabiliriz” demek zor satılır; ama “150MB bellek tasarrufu sağlarsak kullanıcıların %10’u için uygulama performansı berbat seviyeden zar zor kullanılabilir seviyeye çıkar” demek satılabilir
Eskiden yazılım gerçekten böyle geliştirilirdi. Bu yüzden Pentium 1 gibi makinelerde bile bugün beklediğimiz şeylerin çoğuna sahip işletim sistemleri gayet iyi çalışabiliyordu. Buna karşılık şimdi, her eksende kelimenin tam anlamıyla yaklaşık bin kat daha fazla kaynağa sahip akıllı telefonlarda bile web sayfası kaydırma takılıyor. Word 95 ekibi sürekli sınırlar ve performans ödünleriyle karşılaşıyordu; sonuç da açıkça ya çalışıyor ya da çalışmıyordu
Sadece daha fazla RAM ekleseydi hâlâ daha kötü bir tasarıma sıkışıp kalacak, kısa süre sonra yine daha fazla RAM satın almak zorunda kalacaktı. Bu değişimin şaşırtıcı yanı yalnızca kaynak kullanımını azaltması değil; boş RAM sayesinde disk önbelleğinin artmasıyla sistemin daha yetenekli ve hızlı hale gelmesi
[1] Örneğin bu tek bir Pi üzerinde çalışıyor ve güncellemelere izin vermediği için çalışan Wikipedia’dan çok daha hızlı: https://encyclopedia.marginalia.nu/article/Hacker_News
Bu yüzden eski bilgisayarlar iyi hissettirmiş, eski oyunlar da bu kadar harika olmuş olabilir
Uğraştığımız sistemlerin karmaşıklığıyla ilgili olabilir. RAM, fiziksel alan, yiyecek, malzeme, zaman, para gibi kaynaklar sınırlıysa, onları nasıl kullanacağını planlamak zorundasın ve akıllı davranmaktan başka çaren yok
Fiilen sınırsız kaynağın varsa istediğin gibi inşa edebilirsin ama nihai durumu önemseme ihtiyacın azalır. Sadece başlarsın; çalıştığında bakarsın
Gerçek bir oyuncu değilim ama birkaç KB/MB’lık ROM kartuşuna bu kadar çok duygu, macera ve eğlence süresi sığdırabilen insan yeteneğine hep şaşırmışımdır. Ocarina Of Time ROM benim iPhone’la çektiğim son fotoğraflardan yaklaşık 8 tanesinin boyutu kadar
Raspberry Pi 2 saniyede 4 milyardan fazla Dhrystone komutu işleyebilir; Pi 4 ise saniyede 10 milyardan fazla
Elbette modern ölçütlere göre 1970’lerin ortasındaki SABRE, bir havayolunun çekirdek sistemi için oldukça temeldi; ama teorik olarak tek bir Pi 2 üzerinde 100’den fazla havayolunun basitleştirilmiş sistemini aynı anda çalıştırmak da mümkün
Modern programlar optimizasyondan çok uzak. Matematik işlemlerinin yoğun olduğu durumlar dışında 1000 kat ya da 10000 kat iyileştirme bile mümkün
Microsoft’un bu sorunu ciddi yaşadığını düşünüyorum. 5 yıl önce 3000 dolarlık bir dizüstü bile Teams görüşmesi, birkaç Office uygulaması ve 30 sekmeli bir tarayıcıyı aynı anda çalıştırınca kabul edilemeyecek kadar yavaşlıyor
Her biri ayrı ayrı test edildiğinde yalnızca o çalışırken sorun yok, ama gerçek insanlar böyle kullanmıyor
Belirli donanımlarda çalışma süresini sınırlamak ve bu sınırı yalnızca açık bir karardan sonra yükseltmek gibi yapay sınırlar çözüm olabilir
Yine de ben performans tarafı “veritabanına aptalca şeyler yapma, geri kalanı için müşteriler bu kaygıya para ödemediğinden umursama” noktasına çıkan iş yazılımları yazdığım için tamamen yanlış anlamış da olabilirim
marginalia.nu güncellemeleri her geldiğinde hep seviniyorum. Bu sitede değerli bir kullanıcısın; paylaşmaya devam etmeni isterim
Teşekkürler. Bir arama motoru hobi projesi yapıyorum ve nedense sürekli “Magnolia” varyasyonlarını arayıp duruyordum. Marginalia adı benim aklımda pek kalmıyor. Şu anda Searx’i anlamaya çalışıyorum
Marginalia’nın son gün, geçen hafta gibi zaman filtresi aramalarını destekleyip desteklemediğini merak ediyorum. Özel anahtar sözcüklere bakınca arama parametreleri yalnızca yıl bazlı görünüyor
year>2005 (beta) belgenin görünüşe göre 2005’ten sonra yayımlandığını belirtir
year=2005 (beta) belgenin görünüşe göre 2005’te yayımlandığını belirtir
year<2005 (beta) belgenin görünüşe göre 2005’ten önce yayımlandığını belirtir
Yıl filtresi de epey kaba; çoğu web sayfasının tarihini doğru yakalamak çok zor
“SSD, diskin herhangi bir yerindeki tek bir baytı her güncellediğinde tüm sayfayı silip yeniden yazmak zorundadır” ifadesinin SSD’ler için gerçekten doğru olup olmadığını merak ediyorum
Ham flash’ta böyle değil. “Boş” all-ones değerinin üzerine yazmak ya da yalnızca 1’i 0’a çevirmek söz konusuysa mümkün. Yazma, okumadan birkaç mertebe daha yavaştır ama silmeden de birkaç mertebe daha hızlıdır; aşınma bütçesine de yalnızca silme işlemleri yansır
SSD denetleyicisi bundan yararlanmıyorsa bu bana kendi kalesine gol gibi geliyor. Yine de içerisi gerçekten log-yapılı ise bunu yapamayabilir diye düşünüyorum
Eskiden popüler birkaç flash yongası için sürücü yazmıştım; o dönemde uğraştığım yongaların tamamı okuma ve yazma için yalnızca sabit boyutlu sayfa düzeyinde G/Ç kullanıyordu
SSD, yongalardan oluşan bir demet olduğuna göre SSD içindeki her yonganın da yalnızca sabit boyutlu sayfa G/Ç’sini desteklemesini beklerim
Denetleyiciler normalde böyle en kötü örüntülerden kaçınmak için over-provisioning, tamponlama, yazmaları yeniden sıralama gibi çeşitli teknikler kullanır; ama bunların da sınırı vardır
SSD’de yazılabilen en küçük birim sayfadır; silinebilen en küçük birim ise birden çok sayfadan oluşan bloktur
Bu yüzden bir yazma işlemi sayfa içindeki yalnızca 1 baytı etkiliyor olsa bile SSD sadece o baytı silemez. Ama bu mutlaka tüm bloğu silmesi gerektiği anlamına da gelmez
SSD “oku-değiştir-yaz” türünde bir işlem yapabilir. Değişecek baytın bulunduğu tüm sayfayı SSD önbellek tamponuna okur, sayfa önbelleğinde yalnızca ilgili baytı değiştirir, boş yeni bir bloğu siler, değiştirilmiş sayfayı önbellekten yeni bloğa yazar ve FTL eşleme tablosunu yeni bloktaki güncellenmiş sayfayı gösterecek şekilde günceller
Dolayısıyla yalnızca 1 bayt değişse bile sayfanın yeniden yazılması gerekir. Ancak içindeki birçok sayfa değiştirilene kadar tüm bloğu silmekten kaçınılabilir
Yazma oldukça sayfalar fiziksel aygıt içinde yer değiştirir. Sürücünün kendisi hangi adresin ne amaçla kullanıldığını, sağlık durumunun ne olduğunu vb. içeren bir harita tutar. Bir tür seyrek depolama yaklaşımıdır
TRIM gibi komutlar, periyodik bakım ve çöp toplama da vardır
Gerçekte dolu olmayan bir sürücüye yazma yapıldığında, verinin gideceği sayfayı bulur, orada veri olup olmadığını kontrol eder, gerekirse oku/değiştir/yaz yapar, veriyi nereye yazacağına karar verir ve sonra yazar. Wear leveling nedeniyle büyük olasılıkla başlangıçtaki yerine geri dönmez
Denetleyicinin performans için çok daha karmaşık adımlar yürüttüğü doğru. Bu yüzden boş ve yeni bir sürücü bir süre daha iyi çalışır; yedek sayfası kalmamış eski ve dolu bir sürücü ise gerçekten yavaşlayabilir
Kaynak olarak ekleyeyim: önbellek tutarlılığına sahip bellek eşlemeli bir flash hızlandırıcının baş mühendisiydim. Linux kullanıcı alanında sürücüyü çok verimli biçimde eşlemeyi sağlıyordu ama sonunda bir süreliğine, yalnızca başka bir sabit disk gibi görünen “kolay” programlama modeline boyun eğdik
Mojeek’teki patronumun da muhtemelen buna çok benzer bir yoldan geçtiğini düşündürdü. Bu yazı geçmişteki sohbetlerle oldukça örtüşüyor
Mojeek 2004’te başladı; iskeletini büyük ölçüde tek bir geliştirici kurdu ve bilgi erişimi ile altyapının neredeyse tamamını inşa etti
Finansman ve donanım kısıtları, 32 bit ve 64 bit ID kararı, sharding, güncelleme hızı gibi şeyler çok tanıdık geliyor
Eski Google’ın “Google dance”i de aklıma geldi. O zamanlar arama sonuçları ayda bir güncellenirdi; şimdi ise her gün dalgalanıyor. Bunların hepsi evrim süreci ve Marginalia’nın web’e büyük teknolojilerin ötesinden başka bir bakış sunması güzel
Okuması güzeldi
Birçok kişi optimizasyonu derin bir kara büyü gibi görüyor ama çoğu zaman sıradan hata düzeltmelerinden bile daha kolay. Aşırı kaynak kullanımını bug ile aynı şekilde ele almak yeterli
Kolayca yeniden üretilebilen hataların çoğunu düzeltmek için sihre gerek olmadığını düşünüyorum. Bir hatayı kurcalayabiliyorsanız genelde sınıflandırabilirsiniz; nadir tasarım kusurları bile yeniden üretilebilir hale gelince çoğunlukla hızla ortaya çıkar
Kimsenin performansına eleştirel gözle bakmadığı yazılım, kolayca yeniden üretilebilen yüzlerce hatası olduğu halde kimsenin debug etmediği yazılım gibidir. Zor olana çarpmadan önce epey uzun süre tek tek yontabilirsiniz
Bu tavrın, insanların dallanma hedef adreslerini davul kafasının CPU’nun komuta ihtiyaç duyduğu ana denk gelecek şekilde ayarladığı eski günlerden kalma bir artık olduğunu düşünüyorum. Kaynakların son derece sınırlı olduğu, her şeyin elle assembly yazıldığı ve global bellek konumlarının programın aşamasına göre farklı anlamlar taşıdığı dönemlerde, zaten çok zeki insanlar performansa eleştirel bakıyordu; bu yüzden onların bulamadığını bulmanız gerekirdi. Modern kodda bu nadirdir
X isteğini Y servisine gönderince hata yeniden üretiliyorsa, suçluyu bulana kadar test vakasını giderek küçültürsünüz
Optimizasyon çoğu zaman mimari bir meseledir. Yeniden kullanılabilecek bir tamponu kopyaladığınız durumlar da vardır ama bunlar çabuk tükenir ve profiler gereken bilgiyi söyler
Büyük performans kazanımları çoğu zaman tüm veri akışını değiştirmekten, kayda değer bir bölümü ortadan kaldırıp kodun gereken işi mümkün olduğunca az adımda yapmasını sağlamaktan gelir
Neden anahtar-değer deposu yerine SQLite seçtiğini merak ediyorum. Yalnızca ID ile okuma istiyor ve başka sütunlara ihtiyaç yok gibi görünüyor; ilişkisel veritabanı gereksiz görünüyor
SQLite’ın tek dosya olma avantajı var. Bu sayede kopyalamak ya da paylaşmak gibi güzel şeyler yapılabiliyor
Kısıtların inovasyonu doğurduğuna dair bir başka örnek olması hoş. İnovasyon, bolluktan çok sınırlar içinde daha sık bulunuyor