Güvenilir, tutarlı ve düşük gecikme süreli verilerle geniş bir kullanıcı tabanına hizmet vermek, herhangi bir arka uç ekibi için çok zor bir iştir. Ledger olarak kendi blockchain temel veri hizmetlerimizi barındırma konusunda stratejik bir seçim yaptık. Üçüncü taraflara güvenmeyerek müşterilerimizin verilerini kendimiz yönetebilir, temel süreçlerin güvenlik yönergelerimize ve performans odaklı Hizmet Düzeyi Hedeflerimize (SLO) uygun olmasını sağlayabiliriz.
Ancak bu strateji kendi zorluklarını da beraberinde getiriyor.
İlk zorluğumuz, bu temel veri sağlama hizmetlerini harika ve parlak noSQL araçlarından uzaklaştırmaktır. Bu yazıda neden bu zor kararı verdiğimizi, karşılaştığımız zorlukları ve elde ettiğimiz faydaları ele alacağım.
Bu makalenin amacı, bizi blockchain verileri için yeni temel depolama katmanımız olarak PostgreSQL'i seçmeye yönlendiren teknik yönleri göstermektir.
Blockchain Verilerine derinlemesine bakış
Blockchain verilerinin birkaç temel özelliği vardır.
Birincisi, sürekli büyüyor ve ondan hiçbir şey silinmiyor. Ancak pratikte, bir blok zincirinin büyük bir kısmı değişmez olsa da, çözülmesi gereken çatışmalar nedeniyle blok zincirinin en genç kısmı değişebilir. Aslında zincir eşler arası bir ağ olduğundan, birkaç meşru blok geçici olarak bir arada bulunabilir. Genellikle eski olan silinir, bu da yeniden düzenleme dediğimiz şeyle sonuçlanır. Uzun lafın kısası, veriler değişmez bir soğuk kuyruk ile nadiren değişen kafa durumu arasında bölünmüştür.
Çözmeye çalıştığımız sorun, blok zincirlerin hataya dayanıklı verilere sahip olmak açısından harika olmasına rağmen, bunları birçok eksene bölmek ve parçalara ayırmak konusunda daha az etkili olmasıdır. Yani bir hesabı etkileyen işlemlerin listesine ulaşmak oldukça zordur. Bitcoin gibi bir blockchain üzerinde hesap bakiyesi almak bile, henüz işlem listeniz olmadığında zorlu bir iştir.
Bu zorlukların üstesinden gelmek için Ledger Explorer Hizmetleri tüm blok zincirini indeksler. Tamamen Scala'da yazılmış, büyük, kritik ve performansa duyarlı bir hizmettir. kedi etkisi yüksek performanslı çalışma süresi. Bitcoin'de 10 RP/s'nin üzerindeyiz ve kuyruk p95 gecikmesini 100 ms'nin altında tutuyoruz. Biz de işe alım yapıyoruz 😊.
Biraz tarih
Hikayemizin başında, şirkete katılmamdan çok önce Ledger veri hizmeti katmanı, gömülü bir Neo4j veritabanı tarafından yönetiliyordu. Her sunum kutusu kendi verilerini indeksliyor ve yerel olarak sunuyordu, bu da birçok soruna neden oluyordu.
Örnekler arasındaki veri tutarlılığı garanti edilmiyordu ve neo4j disk ve ram kullanımıyla birlikte dizine eklenmesi gereken durumun boyutu ölçeklenebilir değildi. Bu sorun şirket büyüdükçe daha da kötüleşti ve yeni örneklerin ortaya çıkmasını giderek zorlaştırdı.
Kötü olayları önceden haber veren kimse daha sonra bu yeni kurulumun ana sürücüsü olarak seçildi: CAP teoreminin AP tarafında yer alan, kümelenmiş, yatay olarak ölçeklenebilir bir veritabanıdır. Veri paylaşımıyla ilgili sorunları çözer ve indeksleme, blockchain uyumlu bileşen ile başsız API sunucuları arasında net bir ayrım yapılmasına olanak tanır.
Ama eğer gerçekten hiçbir zaman okuyamayacaksak, tarihsel durumun tamamını elimizde bulundurmanın ne anlamı var?
Kullanım durumumuzla ilgili olarak, ham geçmiş verilere nadiren ihtiyaç duyulur çünkü kullanıcımızın hesap durumu buradan toplanabilmektedir. Bu bizi Cassandra dağıtılmış veritabanını temel alan mevcut veri depolama çözümüne meydan okumaya yöneltti.
Her ne kadar terabayt aralığında olsa da, blockchain başına saklamamız gereken veri hacmi “büyük veri” olarak adlandırılabilecek boyutta değil. Üstelik, sorguların çoğunu yanıtlamak için kullanılacak olan kısmı (diğer adıyla Sıcak yol) daha da küçüktür. Günümüzde 16 TB'tan fazla NVMe SSD depolama alanına sahip ticari donanım sunucularını kolaylıkla bulabilirsiniz. Dikey ölçeklendirme çok güçlü bir araçtır ve ilişkisel veritabanı da öyledir.
Son olarak, mevcut Cassandra kurulumunda yaşadığımız ana sorun, ne israf eden depolama modeli ne de yetersiz veri kullanım durumuydu; geliştirici dostu olmamasıydı. Cassandra'da yeni bir veri tabanlı özellik geliştirmenin gereksiz derecede zaman alıcı olduğu kanıtlandı. Veri sağlamamız gereken her yeni ekseni hayata geçirmek için çabaladık.
Ekibimizin veri modelleme becerileri ve SQL yeterliliği konusundaki uzmanlığı göz önüne alındığında, PostgreSQL mükemmel adaydı. Bu çözüm, savaşta test edilmiş, sağlam ve genişletilmesi kolay olduğundan ideal bir seçimdir.
Neden NoSQL yerine SQL'i seçtik:
- Bakiyeleri okur / yazar: Blockchain verilerinin kullanım durumu, yazma yerine okumalara göre oldukça çarpıktır (blockchain, Polygon gibi bir blockchain için bile çok makul bir hızda çok az veri yazar). Cassandra'nın çok yüksek miktarda yazma işlemi gerçekleştirme yeteneği vardır; okuma yolu aslında uzun yazma yolundan daha fazla.
- İndeksleme desteği: Endeksler, sorgulara ve yeni iş senaryolarına veya fırsatlara yanıt veren bir DBMS'nin önemli bir bileşenidir. Cassandra'nın indeksleme desteği sınırlıdır. Dizinler yalnızca sorgunun, sorgunun çalışacağı bölümü sınırlamanın bir yolunu zaten belirtmesi durumunda etkilidir. Burada sahip olmanın maliyetini ödüyoruz keyfi dağıtılmış veri tabanı. Endeksler için PostgreSQL desteği verimli, genişletilebilir ve ileri düzeydedir.
- Toplama desteği: Toplama için aynı durum; Cassandra çok bölümlü toplamaya izin vermediğinden ve sorgu dilinde hiçbir GROUP BY cümleciğine tolerans göstermediğinden desteği biraz eksiktir. PostgreSQL, aralıklar ve jsonb blob'lar gibi egzotik veri türlerinde bile kapsamlı bir toplama desteği sunar.
- Veri modelleme: Cassandra, veri modellemenin mümkün olma şeklini çok ama çok sınırlayıcıdır. Yanıtlamak istediğiniz neredeyse her istek için bir tablo oluşturulmalı ve veriler büyük satırlara normalleştirilmemelidir (tam olarak geniş sütun deposu C*'nın yönü ve ayrıca yazarların çok ucuz olduğu gerçeği). PostgreSQL, blok zincirinin ilişkisel yönünden (çağrılar, işlemler, bloklar) yararlanmamıza ve yedek disk alanından yararlanmamıza olanak tanıyarak verilerin yeniden kullanımını teşvik eder.
- Geçici sorgular ve denetim: SQL'in tam standardını kullanabilmek ve rastgele sorgular yapabilmek, potansiyel hata kök nedenini araştırıp arayabileceğimiz veya gelecekteki kullanım durumları için keşif verilerine sahip olabileceğimiz anlamına gelir. Veritabanını aptal bir depolama yerine gerçekten etkileşimli ve akıllı bir araç olarak kullanabiliriz. Bunu Presto, Spark vb. gibi kapsamlı ve maliyetli bir analitik bilgi işlem kümesi olmadan Cassandra'da yapıyoruz (ve çıplak donanım sunucuları üzerinde çalıştığımız için, EMR gibi kolayca oluşturulan dağıtılmış veri analizi araçlarına erişimimiz yok).
- Depolama alanı kullanımı: Cassandra'nın varsayımı, depolamanın çok ucuz olduğu ve kümenin yeni makinelerle kolaylıkla genişletilebileceği yönündedir. Bu şu demek oluyor hem endeksler hem de toplamalar üzerindeki tüm sınırlamalar depolama ile ödenmelidir. Küresel olarak verimli endekslerin olmaması ve birleştirme desteği, sorgulamak istediğimiz her eksen için tablonun tamamının bir kopyasını denormalize etmemiz ve saklamamız gerektiği anlamına gelir. PostgreSQL bize terabaytlarca depolama alanı ayırıyor.
- Tutarlılık: Cassandra dağıtılmış, AP odaklı bir veritabanı olduğundan (iletişim, düğümler arasındaki dedikodularla yapılır), tutarlılık yalnızca yazma açısından nihaidir. Her ifadenin tutarlılık politikasını hem okuma hem de yazma için ayarlayabilirsiniz, ancak bu veritabanının amacı hiçbir zaman güçlü bir tutarlılığa sahip olmak olmadı. PostgreSQL'in kritik görevlerde kullanılma konusunda güçlü bir geçmişi vardır ve son derece dayanıklıdır. Merkezi olmak aynı zamanda yazma yolunda herhangi bir ağın bulunmadığı anlamına da gelir.
- İşlemler ve MVCC:
- İşlemler: Cassandra destekliyor yalnızca hafif işlemler DML sorgularında. Bazı toplu işlemler uygulanabilir (dok) ancak çok sayıda uyarı var, yani korkunç bir performansa sahip olmamak için satırların aynı sunucuda (= bölüm) olması gerekiyor.
- MVCC: Cassandra satır zaman damgasını destekler ancak MVCC'nin tamamı garanti edilmez. Sıkıştırma eski verileri silebilir ve C*'ya bunun silinmemesi gerektiğini söylemenin bir yolu yoktur (örneğin, PG'deki bir işlemde olduğu gibi).
- PostgreSQL, kullanıcılarımıza tutarlı bir okuma yolu sağlayan güçlü bir MVCC modelini destekler.
- Kalıp: PostgreSQL, veritabanını kolayca çalıştırmak için yaygın olarak kullanılan daha birçok araca sahiptir. Üstelik şöyle bir araç uçuş yolu veritabanı şemasının güçlü bir versiyonunu korumamızı sağlar. Bunu zaten kod tabanımızla başarıyla entegre ettik. Cassandra'da bu olgunluk seviyesinin eşdeğeri yok.
- Yatay ölçeklenebilirlik: Cassandra'nın en önemli satış noktası budur. Verileriniz genişledikçe daha fazla makine ekleyin. Parçalama ve bölümlemenin manuel olarak yapılması gerekmediğinden PostgreSQL için eşdeğeri yoktur.
Nasıl ölçeklendirmeyi planlıyoruz?
Gördüğümüz gibi Postgres kurulumunu kullanmanın tek dezavantajı hem okuma hem de depolama açısından ölçeklendirmedir. Bu sınırlamayı aşmak için ne yapabiliriz?
Elimizdeki ilk etkili araç, desteklediğimiz her protokolü veya blok zincirini kendi veritabanına ayırmaktır, böylece hacim ve trafiğe uygun şekilde ölçeklendirilebilir. İş alanına göre segmentasyon, ilk ölçeklendirme katmanını sağlar.
Bu kavramı daha da ileri götürerek, soğuk, geçmiş verileri de zamansal bölümlere ayırabiliriz. Postgres'in en son sürümleri, verilerin bir makine kümesi arasında sorunsuz bir şekilde taşınmasına olanak tanıyan bölümlenmiş tabloların kullanılabilirliğini büyük ölçüde geliştirdi. Örneğin, geçmiş verilerin çoğunu barındırmak için daha az bilgi işlem gücüne sahip daha ucuz makineler kullanabilir, aynı zamanda toplu tabloları ve kullanıcının en son işlemlerini barındırmak için kullanıcıya hizmet veren RAM yığınlı devasa devleri koruyabiliriz.
Bu yaklaşım bizim kullanım durumumuzda çok iyi çalışıyor çünkü geçmiş depolamada bölümler arası yabancı anahtarlar yok (sonuçta her şey bloğa bağlı). Ana sunucu açısından bakıldığında, bölümleme ve postgres_fdw uzantısı kullanılarak geçmiş verilere şeffaf bir şekilde erişilebilir.
Tüm bunların yerine getirilmesine yardımcı olmak için TimescaleDB uzantısına da baktık. Bu uzantı, temel postgres'e birçok işlevsellik ekler ve bunların çoğu, kullanım durumlarımıza mükemmel uyum sağlar:
- Tabloların sütun gibi bir zamana göre otomatik olarak bölümlenmesi (bizim durumumuzda bunu blockchain yüksekliğini referans olarak alarak uyarlıyoruz).
- Eski parçaların otomatik, veri türüne duyarlı ve sütun tabanlı sıkıştırılması. Bu, çok benzer veriler üzerinde en gelişmiş algoritmaları kullanarak neredeyse mükemmel bir sıkıştırma oranı sağlar.
- Geçmiş bakiyeleri ve piyasa veri grafiklerini kolayca hesaplamak için verimli zaman aralığına dayalı toplama.
Depolamayla ilgili denemelerin henüz başındayız ve bu, birçok kullanım senaryosunun kilidini açıyor. Az miktarda veri kullanan kavramların kanıtı (Ethereum ana ağında ~10k blok, yani yaklaşık 2 günlük veri) %40'a varan disk alanı azalması gösterdi.
Gördüğümüz gibi, doğru stratejiyi kullandığımız sürece veri hacmi sorun değil. Peki kullanıcı tabanımızın boyutuna göre nasıl ölçeklenebiliriz?
Burada zaten güzel bir avantajımız var: Blockchain verilerinin tamamını indeksliyoruz. Böylece ihtiyaç duyulan depolama, kullanıcı sayısı gibi değil, toplam blockchain boyutu kadar artacaktır. Depolama ve okuma optimizasyonları çözünürlük açısından tamamen diktir.
Bu kurulum, sunulması gereken okuma hacmiyle orantılı olarak çok düşük yazma ihtiyacıyla birleştiğinde, sınıflandırma lideri-takipçi kopya modeli için rüya kurulumudur. Performansı ve verimi daha da artırmak için postgres okuma replikalarını API sunucularıyla aynı makinelere yerleştirebilir ve ağ gidiş dönüşlerini atlamak için UNIX etki alanı soketlerinden yararlanabiliriz.
Burada okumalarımızı ölçeklendirmek için kullanabileceğimiz bir veri çoğaltma stratejisi örneği verilmiştir. Açık gri kutular tek sunucuları temsil eder. Burada, depolama ve kullanıcılar arasında minimum aktarım süresini sağlamak için API bölmelerinin doğrudan en sıcak verilerin kopyalarıyla aynı yerde bulunduğunu görebiliriz. Daha önce açıklanan arşiv örnekleri, şemayı çok fazla karmaşıklaştırmamak için temsil edilmemiştir.
Son Sözler
Uzun süredir Cassandra kullanıcısı olarak, tasarımı açısından çok çeşitli uygulamalara uygun harika bir veritabanı olduğunu vurgulamak isterim. Ne yazık ki Ledger'ın bunu kullanma kararı hiçbir zaman gerçekleşmeyen bir veri kullanım senaryosuna göre yapıldı.
Ekibimizin üretkenliği etkilendi ve çözmemiz gereken zorlukları sabırsızlıkla beklerken kurşunu ısırmayı ve batık maliyet yanılgısına düşmemeyi seçtik.
Çoğu durumda verileriniz büyük veri değildir. Veri dağıtımını yönetmek çoğu durumda zor bir iş değildir ve tam teşekküllü dağıtılmış bir veritabanının ödünleşimlerinin gerçekten dikkatle değerlendirilmesi gerekir. Dikkate alınması gereken en önemli nokta geliştirici deneyimidir, çünkü değerli zamanı başka herhangi bir şeyi oluşturmak için serbest bırakır. Bu, yoğun yatırım yapmamız gereken gerçek kullanım durumudur.
- SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
- PlatoAiStream. Web3 Veri Zekası. Bilgi Genişletildi. Buradan Erişin.
- Adryenn Ashley ile Geleceği Basmak. Buradan Erişin.
- PREIPO® ile PRE-IPO Şirketlerinde Hisse Al ve Sat. Buradan Erişin.
- Kaynak: https://www.ledger.com/blog/serving-web3-at-web2-scale
- :vardır
- :dır-dir
- :olumsuzluk
- $UP
- 10
- 10K
- 20
- a
- kabiliyet
- Yapabilmek
- erişim
- erişilen
- Hesap
- karşısında
- aslında
- uyarlamak
- eklemek
- Ekler
- bağlı
- avantaj
- toplanma
- algoritmalar
- Türkiye
- izin vermek
- veriyor
- zaten
- Ayrıca
- Rağmen
- miktar
- an
- analiz
- analytics
- ve
- cevap
- herhangi
- bir şey
- api
- uygulamaları
- uygulamalı
- yaklaşım
- uygun olarak
- Arşiv
- ARE
- etrafında
- Sanat
- göre
- AS
- boy
- yönleri
- varsayımı
- At
- mevcut
- farkında
- uzakta
- EKSENLER
- eksen
- Backend
- Bakiye
- bakiyeler
- baz
- merkezli
- Temel
- BE
- Çünkü
- olmuştur
- önce
- Başlangıç
- Behemotlar
- olmak
- faydaları
- arasında
- Büyük
- büyük Veri
- Bit
- Bitcoin
- Engellemek
- blockchain
- blockchain verileri
- blockchains
- Blokları
- her ikisi de
- kutu
- kutular
- Getiriyor
- Böcek
- inşa etmek
- iş
- fakat
- by
- çağrı
- aramalar
- CAN
- aday
- kapak
- dikkatlice
- dava
- durumlarda
- Sebeb olmak
- neden
- merkezi
- zincir
- meydan okuma
- zorluklar
- zor
- değişiklik
- değiştirme
- ucuz
- daha ucuz
- daha ucuz makineler
- seçim
- Klinik
- seçti
- seçilmiş
- açık
- Küme
- kod
- kod tabanı
- soğuk
- Sütun
- kombine
- emtia
- Yakın İletişim
- şirket
- karmaşıklıklar
- bileşen
- hesaplamak
- kavram
- kavramlar
- dikkate
- kabul
- tutarlı
- Serin
- çekirdek
- Ücret
- olabilir
- çevrimiçi kurslar düzenliyorlar.
- kritik
- akım
- veri
- veri analizi
- bilgi paylaşımı
- veri saklama
- veritabanı
- Günler
- karar
- tarif edilen
- Dizayn
- Geliştirici
- gelişen
- zor
- direkt olarak
- kir
- dağıtıldı
- dağıtım
- bölünmüş
- do
- yok
- yapıyor
- domain
- Dont
- olumsuz
- rüya
- sürücü
- gereken
- e
- her
- kolayca
- kolay
- kenar
- Etkili
- verimli
- başka
- gömülü
- vurgulamak
- etkinleştirmek
- teşvik edici
- artırmak
- sağlamak
- olmasını sağlar
- sağlanması
- Eşdeğer
- vb
- Ethereum
- ETHEREUM ANA AĞ
- Hatta
- nihai
- hİÇ
- Her
- her şey
- örnek
- mevcut
- Egzotik
- genişletir
- deneyim
- Uzmanlık
- keşfetmek
- kâşif
- uzatmak
- uzatma
- kapsamlı, geniş
- gerçek
- Düşmek
- Özellikler(Hazırlık aşamasında)
- Özellikler
- az
- bulmak
- Ad
- uygun
- İçin
- yabancı
- ileri
- dostluk
- itibaren
- tam
- tam teşekküllü
- tamamen
- işlevsellikleri
- daha fazla
- gelecek
- alma
- verilmiş
- Küresel
- gol
- gidiş
- grafikler
- gri
- harika
- grup
- Büyümek
- Büyüyen
- garanti
- kuralları yenileyerek
- vardı
- Zor
- donanım
- Var
- sahip olan
- baş
- ağır şekilde
- yükseklik
- yardım et
- okuyun
- Yüksek
- büyük ölçüde
- tarihsel
- ev sahibi
- SICAK
- sıcak
- Ne kadar
- Nasıl Yapılır
- Ancak
- HTML
- HTTPS
- i
- ideal
- if
- değişmez
- etkiledi
- uygulanması
- gelişmiş
- in
- giderek
- indeks
- Endeksler
- örnek
- entegre
- interaktif
- içine
- Yatırım yapmak
- ilgili
- konu
- sorunlar
- IT
- ONUN
- kaydol
- katıldı
- jpg
- sadece
- koruma
- anahtar
- anahtarlar
- Nezaket.
- Eksiklik
- dil
- büyük
- Gecikme
- son
- tabaka
- Led
- Defteri kebir
- meşru
- az
- seviye
- Kaldıraç
- ışık
- hafif
- sevmek
- sınırlama
- sınırlamaları
- Sınırlı
- Liste
- küçük
- lokal olarak
- Uzun
- baktı
- bakıyor
- Çok
- Düşük
- Makineler
- yapılmış
- Ana
- mainnet
- korumak
- çoğunluk
- Yapımı
- yönetmek
- yönetme
- el ile
- çok
- pazar
- Piyasa verileri
- olgunluk
- maksimum genişlik
- Mayıs..
- anlamına geliyor
- metal
- göç
- en az
- misyonlar
- model
- Modelleme
- Daha
- Dahası
- çoğu
- hareket
- çok
- şart
- yani
- neredeyse
- gerek
- gerekli
- ihtiyaçlar
- ne
- ağ
- asla
- yeni
- güzel
- yok hayır
- düğümler
- hiçbir şey değil
- numara
- sayısız
- hedefleri
- of
- on
- ONE
- bir tek
- işletmek
- Operasyon
- Fırsatlar
- or
- sipariş
- bizim
- kendimizi
- tekrar
- Üstesinden gelmek
- kendi
- ödenmiş
- Bölüm
- partiler
- yol
- model
- armut
- eşler arası
- MÜKEMMEL OLAN YERİ BULUN
- performans
- perspektif
- yer
- plan
- Platon
- Plato Veri Zekası
- PlatoVeri
- bakla
- Nokta
- politika
- Çokgen
- mümkün
- postgreSQL
- potansiyel
- güç kelimesini seçerim
- güçlü
- uygulama
- Sorun
- Süreçler
- verimlilik
- kanıt
- oran
- önermektedir
- protokol
- kanıtlanmış
- sağlamak
- sağlanan
- koymak
- sorgular
- RAM
- menzil
- oran
- daha doğrusu
- oran
- Çiğ
- Okumak
- gerçek
- Gerçekten mi
- makul
- azalma
- ilişkin
- ilgili
- güvenilir
- reorganizasyon
- cevap
- kopya
- temsil etmek
- temsil
- talep
- esnek
- çözüm
- çözüldü
- Ortaya çıkan
- yeniden
- krallar gibi yaşamaya
- gürbüz
- kök
- yuvarlak
- SIRA
- koşmak
- koşu
- aynı
- Scala
- ölçeklenebilir
- ölçek
- ölçekleme
- sorunsuz
- Ara
- güvenlik
- görmek
- görüldü
- bölüm
- bölünme
- Satışa
- satış noktası
- hizmet
- Hizmetler
- servis
- set
- kurulum
- birkaç
- Kırma işlemi
- paylaşımı
- kısa
- şov
- yan
- benzer
- beri
- tek
- beden
- becerileri
- küçük
- daha küçük
- akıllı
- So
- çözüm
- ÇÖZMEK
- çözer
- biraz
- uzay
- Kıvılcım
- Yumurtlamak
- SQL
- standart
- Eyalet
- Açıklama
- hafızası
- mağaza
- Öykü
- Stratejik
- Stratejileri
- güçlü
- şiddetle
- Başarılı olarak
- destek
- Destekler
- tablo
- Bizi daha iyi tanımak için
- alma
- Görev
- takım
- Teknik
- söylemek
- şartlar
- göre
- o
- The
- Blok
- Devlet
- ve bazı Asya
- sonra
- Orada.
- Bunlar
- onlar
- Üçüncü
- üçüncü şahıslar
- Re-Tweet
- verim
- zaman
- için
- çok
- araç
- araçlar
- Toplam
- TAMAMEN
- trafik
- işlem
- işlemler
- transfer
- şeffaf
- tip
- türleri
- eninde sonunda
- altında
- altında yatan
- ne yazık ki
- unix
- açıyorsa
- boşu boşuna
- us
- KULLANILABİLİRLİK
- kullanım
- kullanım
- kullanım durumu
- Kullanılmış
- kullanıcı
- kullanıcılar
- kullanma
- genellikle
- Değerli
- çeşitlilik
- dikey
- çok
- hacim
- istemek
- oldu
- Yol..
- we
- Web2
- Web3
- İYİ
- Ne
- Nedir
- ne zaman
- hangi
- süre
- sırasında
- bütün
- neden
- geniş
- geniş ölçüde
- irade
- ile
- olmadan
- çalışır
- yazmak
- yazılı
- sen
- genç
- zefirnet