22 Kas 2025·8 dk
Doug Cutting'in Lucene ve Hadoop'u: Aramadan Büyük Veriye
Doug Cutting'in Lucene ve Hadoop'unun aramayı ve dağıtık veri işlemeyi modern veri ekipleri için nasıl yaygın açık kaynak yapı taşlarına dönüştürdüğünü öğrenin.
Doug Cutting'in Lucene ve Hadoop'unun aramayı ve dağıtık veri işlemeyi modern veri ekipleri için nasıl yaygın açık kaynak yapı taşlarına dönüştürdüğünü öğrenin.
Lucene ve Hadoop beklenmedik derecede pratik bir hikâye anlatır: bir kez bilgiyi hızlı arama için dizinleyebildiğinizde, sonraki zorluk tek bir makinenin kaldırabileceğinden daha fazla veriyi işlemektir. Birlikte, “arama”yı ve “dağıtık hesaplamayı” niş, pahalı yeteneklerden ekiplerin sıradan donanımla benimseyebileceği yapı taşlarına dönüştürdüler.
Bu yazı bir çalışan tarihçedir; puanlama formüllerine veya dağıtık sistem teorisine derin bir dalış değildir. Amaç, insanların karşılaştığı sorunları, ilerlemeyi mümkün kılan basit fikirleri ve bu fikirlerin neden modern araçlarda hâlâ ortaya çıktığını bağlamaktır.
Apache Lucene, geliştiricilerin uygulamalarına yüksek kaliteli arama eklemesini kolaylaştırdı: metni dizinlemek, hızlı sorgulamak ve her şeyi yeniden icat etmeden yinelemeler yapmak.
Apache Hadoop farklı bir acıyı ele aldı: kuruluşlar günlükleri, tıklama akışlarını ve tek bir sunucuya sığmayacak kadar büyük veri setlerini biriktiriyordu. Hadoop, bu verileri birçok makineye (HDFS) nasıl dağıtıp üzerinde toplu işler (MapReduce) çalıştırabileceğinizi sundu—başından itibaren dağıtık bir sistem el ile inşa etmek zorunda kalmadan.
Bu projelerden önce birçok ekip ya pahalı tescilli sistemler almak ya da yavaş, elle yürütülen iş akışlarını kabul etmek zorundaydı. Lucene ve Hadoop bu engeli düşürdü.
Lucene ve Hadoop öncesi hangi problemlerin olduğunu, Doug Cutting’in çalışmalarının neden geliştiricilerde karşılık bulduğunu ve fikirlerin nasıl bağlandığını—dökümanları dizinlemeden kümeleri koordine etmeye kadar—görmüş olacaksınız.
Sonunda şu etkiyi anlamış olmalısınız: yığınınız Elasticsearch, Spark, bulut nesne depolama veya yönetilen hizmetleri kullansa bile, pek çok temel kavram Lucene ve Hadoop ile yaygınlaştı.
Doug Cutting, çağdaş veri ekipleri için iki ayrı “varsayılan” aracı şekillendiren nadir mühendislerden biridir: arama için Apache Lucene ve dağıtık veri işleme için Apache Hadoop. Her iki proje de bir kişiden çok daha büyük hâle gelmiş olsa da, Cutting'in erken teknik kararları ve açık iş birliğine bağlılığı yönü belirledi.
Cutting'in tutarlı teması erişilebilirlikti. Lucene, yüksek kaliteli aramayı sadece büyük şirketlerin özelce inşa edebileceği bir sistem yerine uygulamanıza gömülebilen bir kütüphane gibi hissettirdi. Sonrasında Hadoop, büyük ölçekli depolama ve hesaplamayı sıradan makineler kümesi üzerinde mümkün kılmayı hedefledi.
Bu motivasyon önemlidir: "büyük veri sadece büyük verinin kendisi için" değil, güçlü yetenekleri sınırlı bütçeli küçük ekiplerin kullanımına sunma çabasıydı.
Lucene ve Hadoop, kararların açık yapıldığı ve yetkinliğin katkıyla kazanıldığı Apache Software Foundation altında büyüdü. Bu model, hata düzeltmeleri, performans iyileştirmeleri, dokümantasyon ve şirketlerden/üniversitelerden gelen gerçek dünya geri bildirimlerinin düzenli akışını teşvik etti.
Cutting’in kişisel katkısı başlangıçta en güçlüydü: ilk mimari, erken uygulamalar ve diğer katkıcıları çekme kredisi. Benimsenme arttıkça topluluk (ve daha sonra birçok şirket) büyük eklentileri yönlendirdi: yeni özellikler, entegrasyonlar, ölçekleme çalışmaları ve operasyonel araçlar.
Faydalı bir yaklaşımla düşünürsek: Cutting “ilk çalışan sürümü” ve etrafındaki kültürü yarattı; açık kaynak topluluğu bu fikirleri kalıcı altyapıya dönüştürdü.
Lucene'den önce bir ürüne "arama" eklemek genellikle küçük bir araştırma projesi inşa etmek anlamına geliyordu. Birçok ekip ya pahalı tescilli yazılımlar aldı ya da ince ayarı zor, ölçeklemesi zor ve yanlış yapması kolay ev yapımı çözümlerle uğraştı.
Arama sadece bir kelimenin nerede geçtiğini bulmak değil. Hız, sıralama ve gerçek dünya metnindeki dağınıklıkla uğraşmak gerekir. Kullanıcı "running shoes" yazıp milisaniyeler içinde yararlı sonuçlar bekliyorsa, özel veri yapıları ve algoritmalar gerekir—ayrıca indeksleme, güncellemeler ve sorguların güvenilir kalmasını sağlamak için dikkatli mühendislik gerekir.
Bir indeks, tüm belgeleriniz için arka kitaptaki indekse benzer: her seferinde her sayfayı taramak yerine bir terimi arayıp direkt onun geçtiği yerlere atlayabilirsiniz. İndeks yoksa arama yavaş olur çünkü her sorgu için yeniden her şeyi okumak gerekir.
Alaka, hangi sonuçların ilk gösterileceğini belirler. Eğer "shoes" ile 10.000 belge eşleşiyorsa, ilk sayfada hangi 10 gösterilmeli? Bu, terim sıklığı, terimin nerede geçtiği (başlık vs gövde) ve terimin tüm koleksiyona göre nadirliği gibi sinyallere bağlıdır.
Web siteleri ve çevrimiçi kataloglar büyüdükçe, "yeterince iyi" arama yetersiz kaldı. Kullanıcılar hızlı sonuç, yazım hatalarına tolerans ve mantıklı sıralama beklemeye başladı. Bunları sunamayan şirketler etkileşim ve satış kaybetti.
Yeniden kullanılabilir bir kütüphane, ekiplerin indeksleme ve sıralamayı baştan icat etmek zorunda kalmamalarını sağladı. Bu, iyi uygulamaların paylaşılmasını kolaylaştırdı ve geliştiricilerin ürünün benzersiz ihtiyaçlarına odaklanmasını sağladı.
Lucene, "aramayı" bir özelliğe dönüştürdü: ürüne ekleyebileceğiniz, araştırma projesi olmasını gerektirmeyen bir şey haline getirdi. Temelde, dağınık metni hızlı ve tutarlı aramaya uygun hâle getirmeye yardımcı olan bir kütüphanedir.
Lucene dört pratik işe odaklanır:
Lucene, günlük arama ihtiyaçları için uygundur:
Lucene'in cazibesi sihir değil—pratiklikti:
Lucene sadece bir şirketin sorununu çözmekle kalmadı; birçok arama uygulaması ve servisin üzerine inşa ettiği güvenilir bir temel oldu. Sonraki birçok arama aracı Lucene'in indeksleme ve alaka yaklaşımını ödünç aldı veya Lucene'i doğrudan motor olarak kullandı.
Arama günlükleri, clickstream'ler, e-posta arşivleri, sensör okumaları ve web sayfaları ortak bir özelliğe sahip: sahip olduğunuz sunucuların satın aldığı hızdan daha hızlı büyürler. Ekipler "her şeyi" saklamaya başlayınca, veri setleri tek bir makineye sığmaz hâle geldi—sadece depolama açısından değil, işleme süresi açısından da.
İlk tepki ölçeği büyütmekti: daha fazla CPU, daha fazla RAM, daha büyük diskler. Bu işe yarar… ta ki yaramaz olana kadar.
Yüksek uç sunucular çok hızlı pahalılaşır ve fiyat sıçraması doğrusal değildir. Ayrıca tüm işlemi tek bir kutuya yatırmış olursunuz; o kutu arızalanırsa her şey arızalanır. Fiziksel sınırlar da vardır: diskler belirli hızlarda döner, bellek tavanları gerçek ve bazı işler veri iki katına çıktıkça zamanında bitmez.
Ölçeği yatay büyütmek yaklaşımı tersine çevirir. Tek güçlü bilgisayar yerine birçok sıradan bilgisayar kullanır ve işi bölersiniz.
Kütüphane taşıma gününü bir zihinsel model olarak düşünebilirsiniz: bir kişi en ağır kutuyu taşıyabilir, ama on kişi daha küçük kutuları taşısa daha çabuk biter—ve bir kişi yorulsa bile geri kalanlar ilerlemeye devam eder. Dağıtık veri işleme aynı fikri depolama ve hesaplama için uygular.
Birçok düşük maliyetli makine kullanmak yeni bir varsayım getirir: bir şeyler sürekli kırılıyor. Diskler ölür, ağlar dalgalanır, düğümler yeniden başlar.
Bu yüzden hedef, hatayı bekleyen ve çalışmaya devam eden bir sistemdi—verinin birden fazla kopyasını saklayarak, hangi iş parçalarının tamamlandığını izleyerek ve kesintiye uğrayan parçaları otomatik yeniden çalıştırarak. Bu baskı—tek bir makineden daha fazla veri ve ölçekte sık arıza gerçeği—Hadoop'un dağıtık işleme yaklaşımının zeminini hazırladı.
Hadoop iki basit vaat olarak anlaşılınca en kolaydır: çok büyük veriyi birçok sıradan makineye saklayın ve o veriyi paralel olarak işleyin. Bu vaatler iki temel parçada görünür: HDFS depolama için ve MapReduce işlem için.
HDFS, tek bir bilgisayara sığmayacak kadar büyük dosyaları sabit boyutlu bloklara böler (blok = parça). Bu bloklar daha sonra kümedeki birçok makineye dağıtılır.
Bir makine arızalandığında veriyi korumak için HDFS her bloğun kopyalarını farklı makinelerde tutar. Bir bilgisayar kapanırsa sistem dosyayı başka bir kopyadan okuyabilir—sizin manuel yedek aramanıza gerek kalmaz.
Pratik sonuç: HDFS'teki bir dizin normal bir klasör gibi davranır, ama arka planda birçok diskin birleşiminden oluşur.
MapReduce, toplu işleme için bir programlama modelidir. İki aşaması vardır:
Klasik örnek, terabaytlarca log üzerinde kelime saymaktır: mapper'lar kendi parçalarında kelimeleri sayar; reducer'lar her kelimenin toplamını toplar.
HDFS + MapReduce bir araya geldiğinde, günlük analizleri, indeksleme hatları, clickstream toplamalaması, veri temizleme gibi büyük toplu işleri tek bir sunucunun ötesinde çalıştırmak pratik oldu. Tek büyük bir makine almak yerine, ekipler daha fazla sıradan kutu ekleyerek ölçekleyebildi ve Hadoop depolama, yeniden denemeler ve paralel yürütmeyi koordine etti.
Lucene ve Hadoop ayrı bölümler gibi görünebilir—biri arama ile ilgili, diğeri "büyük veri" ile ilgili. Ama ortak bir zihniyeti paylaşırlar: gerçek ekiplerin çalıştırabileceği, genişletebileceği ve güvenebileceği pratik araçlar inşa etmek, sadece zekice bir prototip yayınlayıp geçmek yerine.
Lucene, birkaç zor işi olağanüstü iyi yapmaya odaklandı—indeksleme, sorgulama ve sıralama—bunları gömülebilir bir kütüphane halinde paketledi. Bu seçim önemli bir ders verdi: benimseme yararlılıkla gelir. Bir araç kolay entegre edilebiliyorsa, hata ayıklaması yapılabiliyorsa ve iyi dokümante edildiyse, orijinal kullanım alanının ötesine yayılır.
Hadoop aynı felsefeyi dağıtık veri işleme için uyguladı. Özel donanım veya niş sistemler gerektirmek yerine, ortak makinelerde çalışmayı ve tek bir sunucuya sığmayan veri sorununu çözmeyi hedefledi.
Verileriniz çok büyükse, onları ağ üzerinden tek güçlü bir makineye kopyalamaya çalışmak, kütüphanedeki her kitabı tek bir masaya taşımaya benzer. Hadoop'un yaklaşımı, işin verinin zaten bulunduğu yere gitmesidir: küçük kod parçalarını birçok makineye gönderirsiniz, her biri yerel dilimini işler, sonra sonuçları birleştirirsiniz.
Bu fikir arama indekslemeyi de yansıtır: veriyi olduğu yerde düzenlersiniz (indeks) böylece sorgular her şeyi tekrar taramak zorunda kalmaz.
Her iki proje de açık iş birliğinden faydalandı: kullanıcılar sorun bildirebildi, düzeltmeler gönderebildi ve operasyonel deneyim paylaşabildi. Benimsemenin ana itici güçleri genellikle gösterişsiz ama kesinleyiciydi—açık dokümantasyon, farklı ortamlarda taşınabilirlik ve şirketlerin tedarikçi kilitlenmesinden korkmadan yatırım yapmalarını sağlayan Apache yönetimi.
Hadoop ekiplerin sabah uyandıklarında "büyük veri" istemesi yüzünden yayılmadı. Yayılmasının sebebi, birkaç yaygın işin tek bir makinede çok pahalı veya çok güvensiz hâle gelmesiydi.
Log işleme erken bir başarıydı. Web sunucuları, uygulamalar ve ağ cihazları büyük miktarda eklemeye dayalı kayıt üretir. Ekipler günlük veya saatlik özetler istiyordu: uç nokta başına hata sayıları, gecikme yüzdeleri, bölgeye göre trafik, en çok referans verenler. Hadoop ham logları HDFS'e atıp planlı işler çalıştırarak bunları özetlemeyi sağladı.
Clickstream analizi doğal olarak ardından geldi. Ürün ekipleri kullanıcı yolculuklarını anlamak istedi—dönüşümden önce ne tıklandı, nerede bırakıldı, kohortlar zaman içinde nasıl davrandı. Bu veri dağınık ve yüksek hacimli, değeri genellikle büyük toplamalardan geliyor.
ETL çekirdek bir kullanım haline geldi. Kuruluşların verisi veritabanları, dosyalar ve satıcı dışa aktarımları arasında dağınıktı. Hadoop, ham veriyi merkezi bir yere koyup ölçekli olarak dönüştürmek ve daha sonra temizlenmiş çıktıları veri ambarlarına veya tüketici sistemlere yüklemek için bir yer sundu.
Bu iş akışlarının çoğu topluydi: veriyi bir pencere (son saat veya gün) boyunca toplarsınız, sonra bunu dakikalar veya saatler süren bir iş olarak işleriniz. Toplu, soru eğilimleri ve toplamlar üzerineyse iyidir; anlık kullanıcı yanıtlama için uygun değildir.
Pratikte, bu Hadoop'un gece raporlarını, periyodik panoları ve büyük yeniden hesaplamaları desteklediği anlamına geliyordu. Etkileşimli, alt-saniye keşif için tasarlanmamıştı.
Büyük bir cazibe noktası daha ucuz işlemti: tek bir pahalı makine yerine ucuz donanımlarla yatay ölçekleme yapabilmek.
Diğeri ise yedekleme yoluyla güvenilirlikti. HDFS verinin birden çok kopyasını tutarak bir düğüm arızalandığında verinin kaybedilmemesini sağlıyordu.
Hadoop'un erken yığını etkileşimli sorgular için yavaş olabilirdi, özellikle hızlı okuma için tasarlanmış veritabanlarıyla karşılaştırıldığında.
Ayrıca operasyonel karmaşıklık getirdi: kümelerin yönetimi, iş zamanlaması, veri formatları ve birçok makinede hataların giderilmesi. Benimsenme genellikle ekiplerin net bir toplu iş yüküne sahip olduğu ve boru hatlarını standardize etme disiplini gösterdiği durumlarda başarılı oldu—Hadoop'u her şeye zorlamaktansa.
Lucene ve Hadoop farklı problemleri çözer; bu yüzden birlikte iyi çalışırlar.
Lucene hızlı getiri ile ilgilidir: metin ve yapılandırılmış alanlar üzerinde arama yaparak ("bu sorgu için şimdi 200 en alakalı olayı bul") hızlı sonuç sunar.
Hadoop büyük dosyalarla çok makinede çalışma ile ilgilidir: veriyi güvenilir şekilde HDFS'te saklar ve paralel işler (tarihsel olarak MapReduce) ile veriyi dönüştürür, toplar ve zenginleştirir.
Basitçe: Hadoop veriyi hazırlar ve ezer; Lucene sonuçları keşfetmeyi kolaylaştırır.
Aylardır biriken ham uygulama loglarınız olduğunu varsayın.
Böylece ağır toplu işlemenin avantajını ve etkileşimli araştırmayı aynı anda elde edersiniz.
Analitik genellikle "genel olarak ne oldu?" sorusunu yanıtlarken, arama "bana özel kanıtı göster" demeye yardımcı olur. Hadoop, devasa girdilerden türetilmiş veri setleri üretmeyi mümkün kıldı; Lucene ise bu veri setlerini keşfedilebilir hâle getirdi—dosyalar yığınını insanların gezebileceği bir şeye dönüştürdü.
Bu ikili zorunlu değildir. Veriniz tek bir veritabanına rahatça sığıyorsa veya yönetilen arama ve analiz hizmetleri ihtiyaçlarınızı karşılıyorsa, Hadoop + Lucene bağlantısı operasyonel yük getirebilir. İkisini ancak gerçekten her ikisine de ihtiyaç duyduğunuzda kullanın: büyük ölçekli işlem ve hızlı, esnek keşif birlikte gerekli olduğunda.
Hadoop sadece büyük dosyaları işleme biçimi sunmakla kalmadı; birçok kuruluşu paylaşılan bir veri platformu düşünmeye itti. Her analiz projesi için ayrı sistemler kurmak yerine ekipler ham veriyi bir kere bırakıp ucuz şekilde saklayabilir ve zaman içinde farklı gruplar bu veriyi yeniden kullanabilirdi.
HDFS tarzı depolama ve toplu işlem alışıldık hale geldikçe bir desen ortaya çıktı: veriyi merkezileştir, sonra üstüne yetenekler kat. Bu değişim depolama, hesaplama ve erişim arasındaki ayrımı netleştirdi:
Bu hem teknik hem kavramsal bir değişimdi. Veri altyapısının yeniden kullanılabilir, yönetimli ve takımlar arasında erişilebilir olması beklentisini getirdi.
Topluluk momentumuyla birlikte insanlar veriyi daha kolay sorgulamanın, güvenilir şekilde yüklemenin ve tekrarlayan iş akışlarını yürütmenin yollarını istedi. Bu geniş anlamda şunları tetikledi:
Daha fazla araç aynı platforma bağlandıkça standartlar yapıştırıcı hâline geldi. Ortak dosya formatları ve paylaşılan depolama desenleri, verinin motorlar ve ekipler arasında daha kolay değiş tokuş edilmesini sağladı. Her araç için her boru hattı yeniden yazmak yerine, kuruluşlar birkaç "varsayılan" format ve dizin konvansiyonunda anlaşabildiler ve platform parçalarının toplamından daha fazlası oldu.
Hadoop un zirve yılları büyük, toplu odaklı işlerdi: veriyi HDFS'e koy, MapReduce'u gece çalıştır, sonra sonuçları yayımla. Bu model tamamen kaybolmadı ama varsayılan olmaktan çıktı; beklentiler "hemen yanıt" ve "sürekli güncelleme" yönünde değişti.
Ekipler saf batch işlemden akış ve yakın-gerçek zamanlı boru hatlarına geçti. Günlük MapReduce koşusunu beklemek yerine, sistemler olayları geldikçe işleyip panoları veya uyarıları hızlıca güncellemeye başladı.
Aynı zamanda yeni hesaplama motorları etkileşimli analizleri pratik kıldı. Bellek içi işleme ve optimize sorgu yürütme için tasarlanmış çerçeveler, yinelemeli işler, keşif analizleri ve SQL tarzı sorgularda klasik MapReduce'u geride bıraktı.
Depolama da değişti. Birçok kuruluş "HDFS evrenin merkezi" yerine daha ucuz ve basit bir ortak veri katmanı olarak bulut nesne depolamaya geçti. Hesaplama daha geçici hâle geldi: gerektiğinde aç, iş bitince kapat.
Hadoop ismiyle anılan bileşenlerin bazıları azalsa da fikirler her yere yayıldı: dağıtık depolama, hesaplamayı veriye yaklaştırma, ucuz donanımda hata toleransı ve paylaşılan "veri gölü" zihniyeti. Araçlar değişse bile mimari desenler normalleşti.
Lucene aynı dalga-patlama döngüsünü yaşamadı çünkü modern arama yığınlarının içinde gömülü temel bir kütüphanedir. Elasticsearch, Solr ve diğer arama çözümleri hâlâ indeksleme, skorlama ve sorgu ayrıştırma için Lucene'e dayanıyor—bu yetenekler arama, gözlemlenebilirlik ve ürün keşfi için merkezi olmaya devam ediyor.
Hadoop bir paket olarak daha az yaygın olabilir, ama temelleri modern veri mühendisliğini şekillendirdi. Lucene ise arama ağırlıklı uygulamaları güçlendirmeye devam ediyor, hatta yeni hizmetlerin ve API'lerin içinde paketlense bile.
"Büyük veri" sistemleri kurmasanız bile, Lucene ve Hadoop arkasındaki fikirlerden faydalanabilirsiniz. Faydalı kısım hangi problemi çözdüğünüzü bilmektir: şeyleri hızlı bulmak (arama) veya çok fazla veriyi verimli işlemek (toplu/dağıtık hesaplama).
Kullanıcılar (veya dahili araçlar) bir sorgu yazıp anahtar kelime, ifade, filtre ve sıralama ile hızlıca alakalı sonuç almak zorundaysa—arama dizinleme bölgesindesiniz. Bu alan Lucene tarzı indekslemenin güçlü olduğu yerdir.
Hedefiniz büyük hacimli veriyi işleyip agregalar, özellikler, dışa aktarımlar, raporlar veya dönüşümler üretmekse—çoğunlukla zamanlanmış bir şekilde—toplu işleme bölgesindesiniz. Bu Hadoop'un normalleştirdiği problem alanıdır.
Kısa bir kestirim:
Araçları seçmeden önce gereksinimlerinizi sınayın:
Seçenekleri incelerken ihtiyaçlarınızı paralel desenlere ve takaslara eşlemekte fayda var; yönetilen vs. kendi barındırdığınız yaklaşımları değerlendirirken operasyonel sorumlulukları maliyetle birlikte kıyaslamak genellikle ham özellik listesinden daha aydınlatıcıdır. Blog benzeri içerikler ve fiyatlandırma kaynakları bu süreçte yardımcı olabilir.
Lucene/Hadoop döneminden alınacak pratik ders şudur: ekipler bu "altyapı fikirlerini" çalışır ürünlere hızlıca dönüştürebildiğinde kazanır. Eğer dahili bir log gezgini, belge arama uygulaması veya küçük bir analiz panosu prototipliyorsanız, sohbet tabanlı bir platform olan Koder.ai uçtan uca kullanılabilir bir uygulamaya daha hızlı ulaşmanıza yardımcı olabilir: ön yüzde React, arka uca Go ile Postgres ve sohbet aracılığıyla yineleme.
Bu, alanlar, filtreler, saklama ve UX gibi gereksinimleri doğrularken özellikle faydalıdır. Planlama modu, anlık görüntüler ve geri alma gibi özellikler ilk deneyleri daha az riskli kılar—kümeler çalıştırmak veya bir arama yığınını ince ayar yapmak gibi daha ağır operasyonel tercihlere bağlanmadan önce.
Lucene ve Hadoop yaygınlaşmadı çünkü sihirliydiler; yayıldılar çünkü yeniden kullanılabilir ilkelere—indeksleme ve dağıtık işleme—sahip yapı taşlarını paketleyip ekiplerin benimsemesine, genişletmesine ve açık kaynak aracılığıyla paylaşmasına izin verdiler.
Lucene, her sorguda tüm içeriği taramak zorunda kalmadan eşleşen belgeleri hızlıca bulabilmeniz için bir dizin oluşturan bir arama kütüphanesidir. Ayrıca pratik ürün ihtiyaçlarını karşılayan bileşenleri de sunar: analizörler (metnin nasıl token'lara ayrıldığı), sorgu ayrıştırma ve alaka (relevance) skorlama.
Hadoop, "daha büyük bir sunucu almak" çözümünün işe yaramadığı noktayı hedefler. Verileri birden çok makineye dağıtarak saklamanıza ve üzerinde paralel toplu işlem (batch) yapmanıza olanak verir; ayrıca makine hatalarını işlemeyi (yeniden deneme ve yedekleme) yerleşik olarak ele alır.
Bir indeks, terimleri (veya diğer token'ları) belgeler/alanlar ile eşleştiren bir veri yapısıdır—kitabın sonunda yer alan dizine benzer.
Pratikte: indeksleme, kullanıcı sorgularının her seferinde her şeyi tekrar okumak yerine milisaniyeler içinde sonuç döndürebilmesi için başta bir kere yapılan iştir.
Alaka (relevance), bir arama motorunun eşleşen sonuçlardan hangilerini önce göstermesi gerektiğini belirleme biçimidir.
Sık kullanılan sinyaller şunlardır:
Ürün araması yapıyorsanız, alan güçlendirmeleri, analizörler ve eşanlamlılar için zaman ayırarak alaka ayarı yapmayı planlayın—bunu sonradan düşünmemek daha iyidir.
HDFS (Hadoop Distributed File System) büyük dosyaları sabit boyutlu bloklara böler ve bunları bir küme üzerindeki makineler arasında dağıtır. Ayrıca her bloğun birden fazla kopyasını farklı makinelerde tutar, böylece bir düğüm arızalansa bile veriler erişilebilir kalır.
Operasyonel olarak, HDFS'i normal bir dosya sistemi gibi kullanırsınız; arka planda Hadoop yerleştirme ve yedeklemeyi yönetir.
MapReduce, iki aşamalı bir toplu işlem (batch) programlama modelidir:
Bunu, terabaytlarca log üzerinden kelime sayımı gibi "her şeyi tarayıp özet üretme" işleri için kullanın.
“Hesaplamayı veriye taşımak”, verilerin zaten bulunduğu makinelerde küçük kod parçalarını çalıştırmak; bunun yerine devasa verileri ağ üzerinden tek bir yere kopyalamaya çalışmamak demektir.
Bu, ağ tıkanıklığını azaltır ve veri büyüdükçe daha iyi ölçeklenir—özellikle büyük toplu işler için.
Yaygın bir desen şudur:
Bu ayrım, ağır işleme ile etkileşimli keşfi birbirine karıştırmaz.
Hadoop'un ilk kazançları, yüksek hacimli ve eklemeye dayalı verilerde ortaya çıktı; değer genellikle toplamalardan geliyordu:
Bunlar genellikle toplu iş akışlarıdır ve dakika/saat gecikme kabul edilebilir.
Basitçe gereksinimlerle başlayın ve bunları karşılayan en basit aracı seçin:
Gecikme, veri boyutu/büyüme hızı, güncelleme modeli ve operasyonel yükü test ederek yanlış kararların önüne geçin. İlgili karşılaştırmalar için blog benzeri içeriğe veya yönetilen vs. kendi barındırdığınız tercihleri değerlendirmek için fiyatlandırma ile ilgili kaynaklara bakmak faydalı olabilir.