şükela:  tümü | bugün
  • çok uzun süre ekşi sözlük'ün teknik tarafını çekip çevirmiş kişi olarak:

    "ekşi sözlük günde milyonlarca sayfa gösterimi yapıyor nasıl dakikada iki tane entry'den fazlasını silemiyor?"

    "entry'lerim hepsini toplasan 28 megabyte ediyor, o kadarlık dosyayı bilgisayarımdan silmem bir saniye sürmez, sen nasıl silemiyorsun?"

    tüm bunların cevabı "gizemli dünyalar" programının bu bölümünde.

    (müzik)

    (uzaktan kainat)

    en başta her şey gibi ekşi sözlük de gaz ve toz bulutuydu. her gaz ve toz bulutu gibi bugün ekşi sözlük'te olan özelliklerin hiçbirini barındırmıyordu. buna "kullanıcı girişi" ve "entry silme" de dahil. istediğiniz nick'le istediğinizi yazabiliyor ve bunları silemiyordunuz.

    entry silme ve kullanıcı girişi ihtiyacı ekşi sözlük'ün dördüncü gününde birinin başkasının nick'iyle de yazabildiğini keşfedip bir arkadaşın nickiyle o zamanki kız arkadaşı hakkında atıp tutmasıyla ortaya çıktı. o dönem ekşi sözlük veritabanı sadece bir metin dosyasından ibaretti. bu yüzden entry silmek istediğimde kanada'daki sunuculardan bu metin dosyasını indiriyor, edit.com ile editleyip alakalı satırları siliyor ve geri upload ediyordum. evet arada birisi eskaza bir şey girdiyse üstüne yazılıyordu. ama neyse ki o dönem o kadar trafiği yoktu. baktım silmek hep gerekecek arabirimini ekledim. bir ay sonra teo "her başlığa aynı entry'yi basma scripti" yazınca mecburen kullanıcı bazlı engelleyebilmek için kullanıcı girişini de eklemiştim.

    birkaç ay sonra sözlüğü detay'dan öğrendiğim asp bilgisiyle access veritabanına geçirdim. bu pek çok performans problemini çözdü. üstelik entry silme gibi işlemleri de arabirimden yapabilme kolaylığı getirdi. başlıkların 50 karakter olma limiti de access'in varsayılan alan genişliği olmasından, benim de görüp "tamam 50 iyidir ya" dememden geliyor.

    site büyüdükçe access de yükü kaldırmamaya başladı. aynı anda birden fazla kullanıcının üstünde işlem yapmasına göre iyileştirilmiş değildi. kullanıcılar birbirlerini bekletiyordu. bu da başkası bir şey yaparken diğerlerine sitenin "takılıyor" görünmesine yol açıyordu.

    bu problemler üzerine de 1999 yılı sonlarına doğru siteyi aynı anda birden fazla sorgu çalıştırabilen sql server 7.0'a geçirdim.

    entry silme işlemi başlangıçta veritabanından kayıtların tamamen silinmesi olarak çalışıyordu. lakin veritabanı büyüdükçe bunun yükü arttı.

    neden böyle?

    bunun iki temel sebebi var. birincisi index:

    veritabanları hızlı kayıt bulmak için index'ler kullanırlar. index'ler erişimde çok hızlılardır fakat index'leri güncellemek ya da içinden kayıt silmek çok pahalı bir işlemdir (bkz: b-tree). veritabanından kayıt silmekle, dosya sisteminden tüm kayıtların toplam boyu kadar dosya silmek arasındaki büyük farklardan biri de budur. 28mb boyunda tek bir dosyayı silmek ile 28 milyon adet 1 byte'lık dosyayı silmek arasındaki fark gibi düşünebilirsiniz. dosya sistemine bağlı olarak biri çat diye olacakken öbürü sizi saatlerce bekletebilir. işin kötü tarafı veritabanları aynı anda bu index'e başka müdahale etmek isteyen olursa onları bekletirler. yani index'e "kilit vururlar". kilitli bir kaynağa birden fazla erişmek isteyen olursa sql server bir süre sonra bu durumu deadlock kabul eder (aslında gerçekte olmamasına rağmen, zamandan kazanmak için) ve talepleri öldürür.

    ikincisi ise tablo:

    veritabanında kayıtlar tablolarda durur. (entry tablosu, kullanıcı tablosu gibi). index'lerden farklı olarak tablolarda yapılan değişimler daha kolay çözümlenebilirler çünkü bunlara daha "dar kapsamlı" kilitler atamak mümkündür (bkz: paglock) (bkz: rowlock). böylece bir tabloda aynı anda iki kaydı güncellemek mümkün olabilir. ancak sql server yoğun talep görürse bu kilitleri israf etmemek için lock escalation dediğimiz bir işlem yapar ve tüm tabloya kilit vurur (bkz: tablock). bu sayede kaynak tasarrufuna gittiğini düşünür. ancak tablo kilitli olduğu zaman güncelleme bitene kadar diğer tüm kullanıcılar o tablonun kilidinin açılmasını beklemek zorunda kalırlar.

    bu da şanssız kullanıcılara 30 saniye bekleme ve sonunda da hata mesajı sayfasıyla karşılaşma olarak yansır. bu sürede sadece kilitsiz anı yakalayan şanslı kullanıcılar sonuç alırlar.

    tablo güncellenirken okumaya devam edebilmek için ülkem yazılımcılarının meşhur batıl çözümü nolock'a ek olarak row versioning gibi çözümler getirilmiştir. ancak bunların hiçbiri tabloyu güncellemek isteyen birden fazla kişiye yardımcı olmaz. index güncellemesine de yardımcı olmaz. iki unsurun toplam gücüyle bir kişi geri kalan herkesi bekletebilir.

    tüm bunların üstüne sql server gibi rdbms sistemlerdeki "r"nin açılımı olan "relational" (ilişkisel) modellerden ötürü tek bir tablonun güncellenmesi hem foreign key hem trigger'larla başka tabloların güncellenmesini tetikleyebilir. bunlar bekletmeyi daha da uzatır, üstelik alaksız tablolarda işlem yapmak isteyenlerin işini de engelleyebilir (entry girilememesi gibi).

    bu veritabanlarındaki her tür güncelleme için geçerlidir. entry düzeltme, mesaj silme, ayar değiştirme. ancak bunlar çoğu zaman aynı anda tek kullanıcı tarafından yapıldığından sıkıntı olmaz.

    entry silmenin de diğerleri gibi aynı anda yüzlerce kişinin otomatik bir yazılımla tek tek entry silmesi senaryosu hesaba katılmadığından aynı probleme yol açması çok normal. bu dediğim gibi yüzlerce kişi "entry editleme" script çalıştırsa da, "mesaj silme" scripti çalıştırsa da olabilecek bir problemdi. silme ve düzeltmeden daha hızlı olsa da entry eklemede de olabilecek bir problemdi. isteyen diğer seçeneklerle deneyip sonucu görebilir.

    bu yüzden günde milyonlarca sayfa gösterip tek kullanıcıya iki entry'yi sildirememe problemi hasıl olur. çünkü sunucu aynı anda yüzlerce silme talebiyle uğraşmaktadır ve aynı anda sadece birini işleyebilmekte, diğer kullanıcıları beklettikçe onların sunucuya yükü artmaktadır. olaylar gelişir.

    bu problemler tüm kullanıcıları ve site performansını olumsuz etkilediğinden mecralar geri kalan kullanıcıların etkilenmemesi için belli limitler koyarlar. koymak zorundadırlar. entry girişinde yıllardır limit olma sebebi budur. twitter'da ikinci twitter hesabı açma sebebim gezi dönemi twitter'ın tweet atma limitine takılmış olmamdı.

    hızlı entry silmeyi sağlamak çözümsüz değil. mesela sistem çok yavaş siliyorsa bile bunları bir kuyruğa atıp zaman içinde silecek yapıları oluşturulabilir. yazarın statüsü "entry'lerini sildi" olarak değiştirilip eğer öyleyse entry'leri gösterilmeyecek olarak ayarlanabilir. şu anki teknik ekip daha iyi bir çözüm de üretebilir. ancak yıllardır böyle bir senaryo öngörmemiş bir tasarımın bu yönde bu zamana kadar değiştirilmemiş olması kadar altyapıda var olmayan queue sistemlerinin bu kadar kısa sürede tasarlanıp kullanıma geçirilmemesi de gayet normal ve makul. bireysel işlem hızını kısıtlamak bu konuya en pratik çözüm. tek tek entry silmek isteyene çözüm var. siteyi komple her şeyi silip terk etmek isteyene de çözüm var. ama "her şeyimi sileyim ama siteyi terk etmiyim"e çözüm düşünülmemiş. bu bir eksiklik ve yeni bir ihtiyaç olabilir ama öngörülememiş olması doğal.

    işin teknik açıklaması budur. kaynakların yıllardır entry göstermeye entry silmekten daha çok ayrılmış olması gayet normal. dünyanın en hızlı silen entry makinasını yaratmak da mümkün. dünyada hiçbir mecrada olmasa bile böyle. anında hayata geçmemesi de makul.
  • gerçekleştirdiğim bir eylem değil. gerçekleştirenlere da hiçbir sözüm yok, haklarıdır.
    hesabı kapatıp gidemiyorlar, çünkü eski kullanıcı isimleriyle yeni üyelik alınabiliyormuş. hoş bir şey değil tabii ki. şurada okumuştum: (bkz: #59067482)

    benim tercihim, sistematik olarak entry silmek değil, en beğenilen entry'lerimi silmek olurdu. ekşi şeyler nereden para kazanacak? senin beğenilmiş entry'lerinden. 5000 entry yerine o 50 entry silinmiş olsa, herkes için çok daha efektif olurdu, sözlük için bile.

    ha tabi şu da var. bunların hepsini kanzuk ve ekibi düşünmeliydi. kendisi, "ben bunlardan daha büyük tepkileri göze aldım" dedi. tepkileri göze almış ama hiçbir şey de düşünmemiş gibi duruyor.

    kendi adıma ufak da bir not düşeyim: tema++ ve ekşicep'i yazdım. kullananlar biliyor ki, otomatik mesaj ve olay kontrolü yapılıyor. sözlüğe yük olmamak için 1dk arayla yaptırıyorum bu kontrolü. ssg ya da kanzuk'a mesaj atıp, bunun kendilerine sorun olup olmayacağını da soracaktım ama siklemezler diye vazgeçtim. çünkü daha evvel benzer sorulara geri dönmemişlerdi.

    düzeltme: leyla olayıyla alakalı mesaj attı bir arkadaşımız. özetl "10-11 sene önce kapanan bazı kullanıcı isimlerinde sorun olmuştur ama leyla olanların hesabı alınamıyor" dedi. kendisine de yazdım, tecrübe ettiğim bir konu değil. doğrusunun ne olduğunu bilmiyorum ama bu bilgiyi de buraya düşmüş olayım.
  • özet olarak : "vurmayın çocuk ölüyor, bütün sorumlusu benim."
  • entry silinmesinin engellendiğini düşünen ve bu nedenle sözlüğe küsen yazarların içini ferahlatması gereken açıklamaya konu eylem.
  • tarihcesi ogrenildiginde yasi yirmilerde olanlar icin suphesiz binlerce ibret vardir.

    daha dogrusu su son 2 haftada olanlar gencler icin buyuk nimet. kafa goz yarilmadan ciddi anlamda bir sey kaybetmeden cok guzel seyler ogreniyorlar. bunu neredeyse her eksisozluk elestirimde yazmaya basladim.

    bakin iste 20'sine varmak uzere olan turkish teknoloji sirketi nasil olur. bilmeyenler icin hatirlatayim, zaminda turkcell'e telefon numarasi verip fatura bilgileri alabiliyordunuz. kimin kac lira borcu var ne kadari odenmis falan. muhtemelen yurtdisinda birebir esdenigi olmasa bugun hala online faturalamada abukluklar yasayabilirdiniz.

    goruntu janti ama gercek ucuzundan nikelaj.

    bu arada hala etrafta kaldiysa bu isin ilmini yapanlardan ufak bi ricam anlatsinlar ogrenelim, hangi anda faz degisimi oluyor da amator ruh kozasindan uzun adam olarak cikiyor?
  • (bkz: entry silmek)
  • anlamadım ama ikna oldum. zaten öncesinde de kendi kendimi ikna etmiştim. hatta bir evre daha öncesinde, entry silinmesini engelleyen kutsal gücün varlığına inanmamıştım bile. tüm bunları düşünmek için bol q harfli terimleri bilmeme de ihtiyacım yoktu. belki biraz iq.

    insanların somut bir olayı değerlendirirken birbirlerini gazlayarak çalıştığı ve bunun, günlük hayatta "tren" dediğimiz kümülatif bir yoğunlaşmaya yol açtığı bir dönemdeyiz. buna en basit örneklerden biri son dönem doğan "resmileşti" akımı.

    öncelikle şunu sormalı insan; "x durumunu yaratan y, bunu neden yapsın?". eğer ki bu soruya olumlu bir yanıt veremiyor isen, yaptığın şey dayanaksız spekülasyondan başka bir şey değildir.

    son günlerde, özellikle toplumumuzun içinde bulunduğu ahmaklığın türlü örneklerine sözlükte rastlamış olmam, yazarların makul değerlendirmeleri dışında, sözlüğe ve sözlük yönetimindeki münferit şahıslara yöneltmiş olduğu hakaretler, aptal talepler ve beyinsiz yorumlar gibi davranışlara sert yanıt vermeme neden oldu. bu durum karmamda yaklaşık 30 puanlık bir düşüşe sebep oldu. çünkü sözlüğün kendi görüşlerine saygı duyması gerektiğini talep eden topluluk, benim görüşlerime sırf kendilerine uymadığı için saygısızlık etmeyi, mesajla kontralar sergilemeyi ihmal etmemişti. neyse lan, karma ne? koy götüne.

    gelelim "entry silme vakası" na tekrardan. bu hadise ilk koptuğundan beri, neden entry yavaşlatma reaksiyonu gösterilebileceğini düşündüm. yanıtı yok. niye olsun amk? muhtelif başlıklarda "kanzuk'un sikinde değiliz, biz gideriz 5.000 tane yeni yazar alır sıradan" tezine tamamen tezat bir şekilde "gitmemiz entry' lerin silinmesi yavaşlatılarak engelleniyor" iddialarında bulunuldu. oğlum bir kere kendi içinde çelişiyorsun. artık bir karar ver, sözlük seni ve entry' lerini istiyor mu istemiyor mu?

    mal olmayın, fikir üretin.
  • sevgili ssg neden eş zamanlı entry silinemediğini açıklamış ama neden ufukta bir queue sistemi* implement etme sözünün verilmediğini açıklamamış, geçiştirmiş, lafı dünyanın hiçbir yerinde yok böyle bir şey'e getirmiş, sarkazmın beline vurmuş. allahtan guru gibi "tercihlerimizi gerçekleşebilir şeylerden seçmemiz gerektiğini" söylememiş.

    böyle bir şey twitter'da yok. ee, yani? twitter gelmiş geçmiş en kullanışlı sosyal ağ mıdır? bilmem kaç yüz bin tweet'i silmek için insanlar ne idüğü belirsiz scriptler indirip kullanmıyorlar mı? twitter bu tasarım kararını ilelebet sürdürmeye and mı içmiştir nedir, abi? bırakın artık sözlüğü twitter'la filan kıyaslamayı. sözlük twitter'a dönüşecekse de herkes bilsin ona göre çizsin rotasını.

    (bkz: reductio ad twitterum)