Yandex'in aşağıdaki veritabanlarına katkısı incelenecektir.
- Tıklama Evi
- Odyssey
- Belirli bir noktaya kurtarma (WAL-G)
- PostgreSQL (logerrors, Amcheck, heapcheck dahil)
- Yeşil erik
Video:
Selam Dünya! Adım Andrey Borodin. Yandex.Cloud'da yaptığım şey, Yandex.Cloud ve Yandex.Cloud müşterilerinin çıkarlarına uygun açık ilişkisel veritabanları geliştirmek.
Bu konuşmada geniş ölçekte açık veritabanlarının karşılaştığı zorluklardan bahsedeceğiz. Neden önemlidir? Çünkü küçük, küçük problemler sivrisinekler gibi sonradan fillere dönüşür. Çok sayıda kümeniz olduğunda büyürler.
Ama asıl mesele bu değil. İnanılmaz şeyler oluyor. Milyonda bir vakada meydana gelen şeyler. Ve bulut ortamında buna hazırlıklı olmanız gerekir çünkü belirli ölçekte bir şey mevcut olduğunda inanılmaz şeyler oldukça olası hale gelir.
Ancak! Açık veritabanlarının avantajı nedir? Gerçek şu ki, herhangi bir sorunla başa çıkmak için teorik bir fırsatınız var. Kaynak kodunuz var, programlama bilginiz var. Bunu birleştiriyoruz ve işe yarıyor.
Açık kaynak yazılım üzerinde çalışırken hangi yaklaşımlar var?
- En basit yaklaşım yazılım kullanmaktır. Protokol kullanıyorsanız, standart kullanıyorsanız, format kullanıyorsanız, açık kaynak yazılımlarda sorgu yazıyorsanız zaten destekliyorsunuz demektir.
- Onun ekosistemini büyütüyorsunuz. Bir hatanın erken tespit edilme olasılığını artırırsınız. Bu sistemin güvenilirliğini artırırsınız. Geliştiricilerin pazardaki kullanılabilirliğini artırırsınız. Bu yazılımı geliştiriyorsunuz. Eğer stil sahibi olmayı bırakıp orada bir şeyler düzelttiyseniz zaten katkıda bulunan birisiniz.
- Anlaşılabilir bir diğer yaklaşım ise açık kaynak yazılımlara sponsorluk yapmaktır. Örneğin, Google'ın dünyanın her yerinden çok sayıda öğrenciye belirli lisans gereksinimlerini karşılayan açık yazılım projeleri geliştirmeleri için anlaşılır miktarda para ödediği ünlü Google Summer of Code programı.
- Bu çok ilginç bir yaklaşım çünkü odağı topluluktan uzaklaştırmadan yazılımın gelişmesine olanak sağlıyor. Google bir teknoloji devi olarak biz bu özelliği istiyoruz, bu hatayı düzeltmek istiyoruz ve burasını kazmamız gerektiğini söylemiyor. Google şöyle diyor: “Ne yapıyorsan onu yap. Nasıl çalışıyorsan öyle çalışmaya devam et, her şey yoluna girecek."
- Açık kaynağa katılmanın bir sonraki yaklaşımı katılımdır. Açık kaynak kodlu yazılımlarda sorun yaşadığınızda ve geliştiriciler olduğunda geliştiricileriniz sorunları çözmeye başlıyor. Altyapınızı daha verimli, programlarınızı daha hızlı ve daha güvenilir hale getirmeye başlarlar.
Açık kaynak yazılım alanındaki en ünlü Yandex projelerinden biri ClickHouse'dur. Bu, Yandex.Metrica'nın karşılaştığı zorluklara yanıt olarak doğmuş bir veritabanıdır.
Ve veritabanı olarak, bir ekosistem oluşturmak ve onu diğer geliştiricilerle (sadece Yandex içinde değil) birlikte geliştirmek için açık kaynak olarak yapıldı. Ve şimdi bu, birçok farklı şirketin dahil olduğu büyük bir proje.
Yandex.Cloud'da Yandex Object Storage'ın yani bulut depolamanın üstünde ClickHouse'u oluşturduk.
Bulutta bu neden önemlidir? Çünkü herhangi bir veri tabanı bu üçgende, bu piramitte, bu bellek türleri hiyerarşisinde çalışır. Hızlı ama küçük kayıtlarınız ve ucuz, büyük ama yavaş SSD'leriniz, sabit sürücüleriniz ve diğer bazı blok cihazlarınız var. Ve eğer piramidin tepesinde verimliyseniz, o zaman hızlı bir veritabanına sahip olursunuz. Eğer bu piramidin tabanında verimliyseniz, ölçeklendirilmiş bir veritabanınız var demektir. Bu bağlamda alttan bir katman daha eklemek veritabanının ölçeklenebilirliğini arttırmaya yönelik mantıklı bir yaklaşımdır.
Bu nasıl yapılabilir? Bu raporda önemli bir nokta bu.
- ClickHouse'u MDS üzerinden uygulayabiliriz. MDS, dahili bir Yandex bulut depolama arayüzüdür. Yaygın S3 protokolünden daha karmaşıktır ancak blok cihaz için daha uygundur. Verileri kaydetmek için daha iyidir. Daha fazla programlama gerektirir. Programcılar programlayacak, hatta iyi, ilginç.
- S3, belirli iş yükü türlerine daha az uyum sağlama maliyetiyle arayüzü daha basit hale getiren daha yaygın bir yaklaşımdır.
Doğal olarak, tüm ClickHouse ekosistemine işlevsellik sağlamak ve Yandex.Cloud içerisinde ihtiyaç duyulan görevi yerine getirmek amacıyla, tüm ClickHouse topluluğunun bundan faydalanmasını sağlamaya karar verdik. MDS üzerinden ClickHouse'u değil, S3 üzerinden ClickHouse'u uyguladık. Ve bu çok fazla iş.
Bağlantılar:
"Dosya sistemi soyutlama katmanı"
"AWS SDK S3 entegrasyonu"
“S3 için IDisk arayüzünün temel uygulaması”
"Günlük depolama motorlarının IDisk arayüzüyle entegrasyonu"
"S3 ve SeekableReadBuffer için günlük motoru desteği"
"Depolama Şerit Günlüğü S3 desteği"
"S3 için Depolama MergeTree ilk desteği"
"MergeTree S3 için tam destek"
"S3 üzerinden ReplicatedMergeTree'yi destekleyin"
"s3 depolama için varsayılan kimlik bilgilerini ve özel başlıkları ekleyin"
"Dinamik proxy yapılandırmasına sahip S3"
"Proxy çözümleyicili S3"
Bu, ClickHouse'da sanal bir dosya sistemi uygulamaya yönelik bir çekme isteği listesidir. Bu çok sayıda çekme isteğidir.
Bağlantılar:
"DiskS3 sabit bağlantıların optimum uygulanması"
"S3 HTTP istemcisi — Yanıt akışını belleğe kopyalamaktan kaçının"
"Yanıt akışının tamamını S3 HTTP'de belleğe kopyalamaktan kaçının
müşteri"
“S3 diski için dosyaları önbelleğe alma ve indeksleme yeteneği”
"Parçaları DiskLocal'dan DiskS3'e paralel olarak taşıyın"
Ancak iş burada bitmedi. Özellik yapıldıktan sonra bu işlevselliği optimize etmek için biraz daha çalışma yapılması gerekiyordu.
Bağlantılar:
"SelectedRows ve SelectedBytes olaylarını ekle"
"S3 isteğinden profil oluşturma olaylarını system.events'e ekle"
"QueryTimeMicroseconds, SelectQueryTimeMicroseconds ve InsertQueryTimeMicroseconds'ı ekleyin"
Daha sonra bunu teşhis edilebilir hale getirmek, izlemeyi kurmak ve yönetilebilir hale getirmek gerekiyordu.
Ve tüm bunlar, tüm topluluğun, tüm ClickHouse ekosisteminin bu çalışmanın sonucunu alması için yapıldı.
Kişisel olarak bana daha yakın olan işlemsel veritabanlarına, OLTP veritabanlarına geçelim.
Bu açık kaynak DBMS geliştirme bölümüdür. Bu adamlar işlemsel açık veritabanlarını geliştirmek için sokak büyüsü yapıyorlar.
Örnek olarak nasıl ve ne yaptığımızı konuşabileceğimiz projelerden biri de Postgres'teki Connection Pooler'dır.
Postgres bir süreç veritabanıdır. Bu, veritabanının işlemleri yürüten mümkün olduğunca az sayıda ağ bağlantısına sahip olması gerektiği anlamına gelir.
Öte yandan bulut ortamında tipik bir durum, bir kümeye aynı anda bin bağlantının gelmesidir. Ve bağlantı havuzlayıcısının görevi, bin bağlantıyı az sayıda sunucu bağlantısına sığdırmaktır.
Bağlantı havuzlayıcısının, baytları veri tabanına verimli bir şekilde ulaşacak şekilde yeniden düzenleyen telefon operatörü olduğunu söyleyebiliriz.
Ne yazık ki, bağlantı havuzlayıcısı için iyi bir Rusça kelime yok. Bazen buna çoklayıcı bağlantılar denir. Bağlantı havuzlayıcısına ne ad vereceğinizi biliyorsanız, o zaman bana söylemeyi unutmayın, doğru Rusça teknik dilini konuşmaktan çok mutlu olacağım.
Yönetilen bir postgres kümesine uygun bağlantı havuzlayıcılarını araştırdık. Ve PgBouncer bizim için en iyi seçimdi. Ancak PgBouncer'da bir takım sorunlarla karşılaştık. Yıllar önce Volodya Borodin, PgBouncer kullandığımızı, her şeyi sevdiğimizi ama nüanslar olduğunu, üzerinde çalışılacak bir şeyler olduğunu bildirdi.
Ve çalıştık. Karşılaştığımız sorunları düzelttik, Bouncer'a yama uyguladık ve çekme isteklerini yukarıya aktarmaya çalıştık. Ancak temel tek iş parçacığıyla çalışmak zordu.
Yamalı Bouncer'lardan çağlayanlar toplamak zorunda kaldık. Çok sayıda tek iş parçacıklı Bouncer'ımız olduğunda, üst katmandaki bağlantılar Bouncers'ın iç katmanına aktarılır. Bu, inşa edilmesi ve ileri geri ölçeklendirilmesi zor, kötü yönetilen bir sistemdir.
Odyssey adı verilen kendi bağlantı havuzlayıcımızı yarattığımız sonucuna vardık. Sıfırdan yazdık.
2019'da PgCon konferansında bu havuzlayıcıyı geliştirici topluluğuna sundum. Artık GitHub'da 2'den biraz daha az yıldızımız var, yani proje canlı ve popüler.
Yandex.Cloud'da bir Postgres kümesi oluşturursanız, bu, kümeyi ileri veya geri ölçeklendirirken yeniden yapılandırılan yerleşik Odyssey'e sahip bir küme olacaktır.
Bu projeden ne öğrendik? Rakip bir projeyi hayata geçirmek her zaman agresif bir adımdır, yeterince hızlı çözülmeyen, bize uygun zaman aralıklarında çözülmeyen sorunlar olduğunu söylediğimizde aşırı bir önlemdir. Ancak bu etkili bir önlemdir.
PgBouncer daha hızlı gelişmeye başladı.
Ve şimdi başka projeler ortaya çıktı. Örneğin Red Hat geliştiricileri tarafından geliştirilen pgagroal. Benzer hedeflerin peşinde koşuyorlar ve benzer fikirleri uyguluyorlar, ancak elbette pgagroal geliştiricilere daha yakın olan kendi özellikleriyle.
Postgres topluluğuyla çalışmanın bir başka örneği de zaman içinde bir noktaya geri yükleme yapmaktır. Bu bir arızadan sonra kurtarmadır, bu bir yedeklemeden kurtarmadır.
Pek çok yedekleme var ve hepsi farklı. Hemen hemen her Postgres satıcısının kendi yedekleme çözümü vardır.
Tüm yedek sistemleri alıp bir özellik matrisi oluşturup şaka yollu bu matristeki determinantı hesaplarsanız sıfır olacaktır. Bu ne anlama gelir? Belirli bir yedekleme dosyasını alırsanız, diğerlerinin parçalarından birleştirilemez. Uygulaması benzersizdir, amacı benzersizdir, içinde yer alan fikirler açısından benzersizdir. Ve hepsi spesifiktir.
Biz bu konu üzerinde çalışırken CitusData WAL-G projesini başlattı. Bu, bulut ortamı dikkate alınarak yapılmış bir yedekleme sistemidir. Artık CitusData zaten Microsoft'un bir parçası. Ve o anda WAL-G'nin ilk sürümlerinde ortaya konan fikirleri gerçekten beğendik. Biz de bu projeye katkıda bulunmaya başladık.
Artık bu projede düzinelerce geliştirici var ancak WAL-G'ye en çok katkıda bulunan 10 geliştirici arasında 6 Yandexoid yer alıyor. Birçok fikrimizi oraya taşıdık. Ve tabii ki bunları kendimiz uyguladık, kendimiz test ettik, kendimiz üretime aldık, kendimiz kullanıyoruz, büyük WAL-G topluluğuyla etkileşim halindeyken bir sonraki adımda nereye gideceğimizi kendimiz buluyoruz.
Ve bizim açımızdan artık bu yedekleme sistemi, çabalarımızı da dikkate alarak bulut ortamı için ideal hale geldi. Bu, Postgres'i bulutta yedeklemenin en iyi maliyetidir.
Bu ne anlama geliyor? Oldukça büyük bir fikri destekliyorduk: Yedekleme güvenli olmalı, çalıştırılması ucuz olmalı ve mümkün olduğunca hızlı geri yüklenmelidir.
İşletmek neden ucuz olsun? Hiçbir şey bozulmadığında, yedeğiniz olduğunu bilmemelisiniz. Her şey yolunda gidiyor, mümkün olduğu kadar az CPU harcıyorsunuz, disk kaynaklarınızın mümkün olduğu kadar azını kullanıyorsunuz ve değerli hizmetlerinizin yükünü engellememek için ağa mümkün olduğunca az bayt gönderiyorsunuz.
Ve her şey bozulduğunda, örneğin yönetici verileri düşürdüyse, bir şeyler ters gitti ve acilen geçmişe dönmeniz gerekiyor, tüm parayı kurtarırsınız çünkü verilerinizin hızlı ve sağlam bir şekilde geri gelmesini istersiniz.
Ve biz bu basit fikri destekledik. Ve bize öyle geliyor ki, bunu uygulamayı başardık.
Ama hepsi bu değil. Küçük bir şey daha istedik. Birçok farklı veri tabanı istedik. Müşterilerimizin tümü Postgres kullanmıyor. Bazı insanlar MySQL, MongoDB kullanıyor. Topluluktaki diğer geliştiriciler FoundationDB'yi destekledi. Ve bu liste sürekli genişliyor.
Topluluk, veritabanının bulutta yönetilen bir ortamda çalıştırılması fikrinden hoşlanıyor. Ve geliştiriciler, yedekleme sistemimiz sayesinde Postgres ile birlikte eşit şekilde yedeklenebilen veritabanlarını korurlar.
Bu hikayeden ne öğrendik? Bir geliştirme bölümü olarak ürünümüz kod satırları değildir, ifadeler değildir, dosyalar değildir. Ürünümüz pull request değildir. Bunlar topluma aktardığımız fikirler. Bu, teknolojik uzmanlık ve teknolojinin bulut ortamına doğru hareketidir.
Postgres diye bir veri tabanı var. En çok Postgres çekirdeğini seviyorum. Toplulukla birlikte Postgres çekirdeğini geliştirmeye çok zaman harcıyorum.
Ancak burada Yandex.Cloud'un dahili bir yönetilen veritabanları kurulumuna sahip olduğu söylenmelidir. Ve bu uzun zaman önce Yandex.Mail'de başladı. Artık Postgres'in yönetilmesine yol açan uzmanlık, postanın Postgres'e taşınmak istemesiyle birikti.
Mail'in buluta çok benzer gereksinimleri vardır. Verilerinizin herhangi bir noktasında beklenmedik üstel büyümeye göre ölçeklenebilmeniz gerekir. Ve posta zaten sürekli olarak birçok istekte bulunan çok sayıda kullanıcının yüz milyonlarca posta kutusundan oluşan bir yüke sahipti.
Ve bu Postgres'i geliştiren ekip için oldukça ciddi bir zorluktu. O zamanlar karşılaştığımız her sorun topluma bildirilirdi. Ve bu sorunlar düzeltildi ve bazı yerlerde topluluk tarafından, hatta diğer bazı veritabanları için ücretli destek düzeyinde ve hatta daha iyi bir düzeyde düzeltildi. Yani PgSQL hacker'ına mektup gönderip 40 dakika içinde yanıt alabilirsiniz. Bazı veritabanlarındaki ücretli destek, hatanızdan daha öncelikli şeylerin olduğunu düşünebilir.
Artık Postgres'in dahili kurulumunda petabaytlarca veri var. Bunlar saniyede milyonlarca istektir. Bunlar binlerce kümedir. Çok büyük ölçeklidir.
Ama bir nüans var. Süslü ağ sürücülerinde değil, oldukça basit donanımlarda yaşıyor. Ve özellikle ilginç yeni şeyler için bir test ortamı var.
Ve test ortamında belirli bir anda veritabanı indekslerinin dahili değişmezlerinin ihlal edildiğini belirten bir mesaj aldık.
Değişmez, her zaman sürdürmeyi beklediğimiz bir tür ilişkidir.
Bizim için çok kritik bir durum. Bu, bazı verilerin kaybolmuş olabileceğini gösterir. Ve veri kaybı düpedüz felakettir.
Yönetilen veritabanlarında takip ettiğimiz genel fikir, ne kadar çaba sarf etsek bile veriyi kaybetmenin zor olacağıdır. Bunları kasıtlı olarak kaldırsanız bile, uzun bir süre boyunca onların yokluğunu görmezden gelmeniz gerekecektir. Veri güvenliği titizlikle takip ettiğimiz bir dindir.
Burada da hazırlıklı olamayacağımız bir durumun olabileceğini düşündüren bir durum ortaya çıkıyor. Biz de bu duruma hazırlanmaya başladık.
Yaptığımız ilk şey bu binlerce kümenin kütüklerini gömmek oldu. Veri sayfası güncellemelerini kaybeden sorunlu ürün yazılımına sahip disklerde hangi kümelerin bulunduğunu bulduk. Tüm Postgres veri kodları işaretlendi. Ve dahili değişmezlerin ihlallerini gösteren mesajları, veri bozulmasını tespit etmek için tasarlanmış kodla işaretledik.
Bu yama pratik olarak topluluk tarafından çok fazla tartışmaya gerek kalmadan kabul edildi, çünkü her özel durumda kötü bir şeyin olduğu ve günlüğe bildirilmesi gerektiği aşikardı.
Bundan sonra logları tarayan izlemeleri yapabildiğimiz noktaya geldik. Şüpheli mesaj durumunda ise nöbetçi memuru uyandırır, nöbetçi ise tamirini yapar.
Ancak! Günlükleri taramak, bir kümede ucuz bir işlemdir ve bin küme için felaket derecede pahalıdır.
adında bir uzantı yazdık. . Geçmiş hatalara ilişkin istatistikleri ucuz ve hızlı bir şekilde seçebileceğiniz bir veritabanı görünümü oluşturur. Ve eğer nöbetçi memuru uyandırmamız gerekirse, bunu gigabayt dosyaları taramadan, ancak karma tablosundan birkaç bayt çıkararak öğreneceğiz.
Bu uzantı örneğin depoda benimsenmiştir. . Kullanmak isterseniz kendiniz kurulumunu yapabilirsiniz. Tabii ki açık kaynak.
Ama hepsi bu değil. Dizinlerdeki değişmez ihlalleri bulmak için topluluk tarafından oluşturulmuş bir uzantı olan Amcheck'i kullanmaya başladık.
Ve bunu geniş ölçekte çalıştırırsanız hataların ortaya çıktığını öğrendik. Bunları düzeltmeye başladık. Düzeltmelerimiz kabul edildi.
Bu uzantının GiST ve GIT dizinlerini analiz edemediğini keşfettik. Destek olmalarını sağladık. Ancak bu destek hala topluluk tarafından tartışılıyor çünkü bu nispeten yeni bir işlevsellik ve burada pek çok ayrıntı var.
Ayrıca, çoğaltma liderinde, ana öğede dizinleri ihlallere karşı kontrol ederken her şeyin iyi çalıştığını, ancak kopyalarda, takipçide yolsuzluk arayışının o kadar etkili olmadığını keşfettik. Tüm değişmezler kontrol edilmez. Ve bir değişmez bizi çok rahatsız etti. Kopyalar üzerinde bu kontrolü sağlamak için toplulukla iletişim kurmak için bir buçuk yıl harcadık.
Tüm protokollere uyması gereken bir kod yazdık. Crunchy Data'dan Peter Gaghan ile bu yamayı uzun süre tartıştık. Bu yamayı kabul etmek için Postgres'teki mevcut B ağacını biraz değiştirmek zorunda kaldı. Kabul edildi. Artık replikalardaki indeksleri kontrol etmek de karşılaştığımız ihlalleri tespit edebilecek kadar etkili hale geldi. Yani bunlar disk ürün yazılımındaki hatalar, Postgres'teki hatalar, Linux çekirdeğindeki hatalar ve donanım sorunlarından kaynaklanabilecek ihlallerdir. Hazırlanmakta olduğumuz sorunların kaynaklarının oldukça kapsamlı bir listesi.
Ancak indekslerin yanı sıra heap yani verilerin saklandığı yer gibi bir kısım da var. Ve kontrol edilebilecek çok fazla değişmez yok.
Heapcheck adında bir uzantımız var. Onu geliştirmeye başladık. Ve buna paralel olarak EnterpriseDB şirketi de bizimle birlikte aynı şekilde Heapcheck adını verdikleri bir modül yazmaya başladı. Sadece biz buna PgHeapcheck adını verdik ve onlar da buna Heapcheck adını verdiler. Benzer işlevlere, biraz farklı bir imzaya sahipler, ancak aynı fikirlere sahipler. Bazı yerlerde bunları biraz daha iyi uyguladılar. Daha önce de açık kaynak olarak yayınlamışlardı.
Ve şimdi onların genişlemesini geliştiriyoruz çünkü bu artık onların genişlemesi değil, topluluğun genişlemesi. Ve gelecekte bu, gelecekteki sorunları önceden bilebilmeleri için herkese sağlanacak olan çekirdeğin bir parçasıdır.
Hatta bazı yerlerde izleme sistemlerimizde hatalı pozitif sonuçların olduğu sonucuna bile vardık. Örneğin, 1C sistemi. Bir veritabanı kullanırken, Postgres bazen içine okuyabileceği verileri yazar, ancak pg_dump okuyamaz.
Bu durum sorun tespit sistemimize yolsuzluk gibi göründü. Nöbetçi uyandırıldı. Görevli olan bitene baktı. Bir süre sonra bir müşterim geldi ve sorunlarım olduğunu söyledi. Görevli sorunun ne olduğunu açıkladı. Ancak sorun Postgres çekirdeğinde.
Bu özellik hakkında bir tartışma buldum. Ve bu özellikle karşılaştığımızı ve bunun rahatsız edici olduğunu, bir kişinin ne olduğunu anlamak için gece uyandığını yazdı.
Topluluk, "Ah, bunu gerçekten düzeltmemiz gerekiyor" diye yanıt verdi.
Basit bir benzetmem var. İçinde kum tanesi olan bir ayakkabıyla yürüyorsanız, o zaman prensip olarak devam edebilirsiniz - sorun değil. Binlerce kişiye bot satıyorsanız hiç kumsuz bot yapalım. Ayakkabılarınızı kullananlardan biri maraton koşacaksa, çok iyi ayakkabılar yapmak ve bunları tüm kullanıcılarınıza göre ölçeklendirmek istersiniz. Ve bu tür beklenmedik kullanıcılar her zaman bulut ortamındadır. Her zaman kümeden orijinal bir şekilde yararlanan kullanıcılar vardır. Buna her zaman hazırlıklı olmalısınız.
Burada ne öğrendik? Basit bir şey öğrendik: Önemli olan topluma bir sorun olduğunu anlatmak. Toplum sorunun farkına varırsa, sorunu çözmek için doğal rekabet ortaya çıkar. Çünkü herkes önemli bir sorunu çözmek istiyor. Tüm satıcılar, tüm bilgisayar korsanları bu komisyona kendilerinin de basabileceğini anlıyor ve onları ortadan kaldırmak istiyor.
Bir sorun üzerinde çalışıyorsanız ve bu sizi rahatsız etmiyorsa, ancak sistemli bir şekilde üzerinde çalışıyorsanız ve sonuçta sorun olarak görülüyorsa, çekme isteğiniz mutlaka kabul edilecektir. Yamanız kabul edilecek, iyileştirmeleriniz ve hatta iyileştirme talepleriniz topluluk tarafından incelenecek. Günün sonunda veritabanını birbirimiz için daha iyi hale getiriyoruz.
İlginç bir veritabanı Greenplum'dur. Oldukça aşina olduğum Postgres kod tabanını temel alan oldukça paralel bir veritabanıdır.
Ve Greenplum'un ilginç bir işlevi var - optimize edilmiş tablolar ekleyin. Bunlar hızlı bir şekilde ekleyebileceğiniz tablolardır. Sütunlu veya satır olabilirler.
Ama kümeleme yoktu yani tabloda yer alan verileri indekslerden birindeki sıraya göre düzenleyebileceğiniz bir işlevsellik yoktu.
Taksideki adamlar yanıma gelip şöyle dediler: “Andrey, Postgres'i tanıyorsun. Ve burada neredeyse aynı. 20 dakikaya geçin. Al ve yap.” Evet, Postgres'i biliyorum, 20 dakikalığına geçiş yapıyorum diye düşündüm - bunu yapmam gerekiyor.
Ama hayır, 20 dakika değildi, aylarca yazdım. PgConf.Rusya konferansında Pivotal'dan Heikki Linakangas'a yaklaştım ve şunu sordum: “Bununla ilgili herhangi bir sorun var mı? Neden ekleme için optimize edilmiş tablo kümelemesi yok?” Şöyle diyor: “Verileri alıyorsunuz. Sıralıyorsunuz, yeniden düzenliyorsunuz. Bu sadece bir iş." Ben: "Ah, evet, sadece onu alıp yapmalısın." Şöyle diyor: "Evet, bunu yapmak için serbest ellere ihtiyacımız var." Bunu kesinlikle yapmam gerektiğini düşündüm.
Birkaç ay sonra bu işlevi uygulayan bir çekme isteği gönderdim. Bu çekme isteği Pivotal tarafından toplulukla birlikte incelendi. Elbette hatalar vardı.
Ancak en ilginç olanı, bu çekme isteği birleştirildiğinde Greenplum'un kendisinde hatalar bulunmasıdır. Yığın tablolarının bazen kümelendiğinde işlemselliği bozduğunu bulduk. Ve bu düzeltilmesi gereken bir durum. Ve az önce dokunduğum yerde. Ve doğal tepkim şuydu: Tamam, izin verin bunu ben de yapayım.
Bu hatayı düzelttim. Tamircilere bir çekme isteği gönderildi. Öldürüldü.
Sonrasında PostgreSQL 12 için Greenplum sürümünde bu işlevselliğin elde edilmesi gerektiği ortaya çıktı. Yani 20 dakikalık macera yeni ilginç maceralarla devam ediyor. Topluluğun yeni ve en önemli özellikleri geliştirdiği mevcut gelişmeye dokunmak ilginçti. Donmuş.
Ama bununla bitmedi. Her şeyden sonra tüm bunlar için belge yazmamız gerektiği ortaya çıktı.
Dokümantasyon yazmaya başladım. Şans eseri Pivotal'ın belgeselcileri geldi. İngilizce onların ana dilidir. Dokümantasyon konusunda bana yardımcı oldular. Aslında önerdiğim şeyi kendileri gerçek İngilizceye yeniden yazdılar.
Ve görünüşe göre macera burada sona erdi. Peki sonra ne oldu biliyor musun? Taksideki adamlar yanıma gelip şöyle dediler: “Hala iki macera var, her biri 10 dakikalık.” Peki onlara ne söylemeliyim? Şimdi ölçekli bir rapor vereceğim, sonra maceralarınızı göreceğiz dedim çünkü bu ilginç bir iş.
Bu vakadan ne öğrendik? Açık kaynakla çalışmak her zaman belirli bir kişiyle çalışmak anlamına geldiğinden, her zaman toplulukla çalışmak demektir. Çünkü her aşamada bir geliştiriciyle, bir testçiyle, bir hackerla, bir belgeselciyle, bir mimarla çalıştım. Greenplum'la çalışmadım, Greenplum'un çevresindeki insanlarla çalıştım.
Ancak! Başka bir önemli nokta daha var - bu sadece iş. Yani geliyorsun, kahve içiyorsun, kod yazıyorsun. Her türlü basit değişmez işe yarar. Bunu normal bir şekilde yapın; sorun olmayacak! Ve oldukça ilginç bir iş. Bu çalışma için Yandex.Cloud istemcilerinden, yani kümelerimizin kullanıcıları olan hem Yandex içinden hem de dışından talep var. Katıldığımız proje sayısının artacağını ve katılımımızın derinliğinin de artacağını düşünüyorum.
Bu kadar. Sorulara geçelim.
Soru oturumu
Merhaba! Bir soru-cevap oturumumuz daha var. Ve Andrey Borodin'in stüdyosunda. Az önce size Yandex.Cloud ve Yandex'in açık kaynağa katkısını anlatan kişi bu. Raporumuz artık tamamen Bulutla ilgili değil ama aynı zamanda bu tür teknolojileri temel alıyoruz. Yandex'in içinde yaptıklarınız olmasaydı, Yandex.Cloud'da da hizmet olmazdı, bu yüzden size kişisel olarak teşekkür ederim. Ve yayının ilk sorusu: "Bahsettiğiniz projelerin her birinde neler yazıyor?"
WAL-G'deki yedekleme sistemi Go'da yazılmıştır. Bu üzerinde çalıştığımız yeni projelerden biri. Kelimenin tam anlamıyla sadece 3 yaşında. Ve bir veritabanı genellikle güvenilirlikle ilgilidir. Bu da veritabanlarının oldukça eski olduğu ve genellikle C dilinde yazıldığı anlamına geliyor. Postgres projesi yaklaşık 30 yıl önce başladı. O halde C89 doğru seçimdi. Ve üzerinde Postgres yazıyor. ClickHouse gibi daha modern veritabanları genellikle C++ ile yazılır. Tüm sistem geliştirme C ve C++'a dayanmaktadır.
Cloud'da harcamalardan sorumlu olan finans yöneticimizin sorusu: "Cloud neden açık kaynağı desteklemek için para harcıyor?"
Burada finans yöneticisi için basit bir cevap var. Bunu hizmetlerimizi daha iyi hale getirmek için yapıyoruz. Hangi yollarla daha iyisini yapabiliriz? İşleri daha verimli, daha hızlı yapabilir ve işleri daha ölçeklenebilir hale getirebiliriz. Ancak bizim için bu hikaye öncelikle güvenilirlikle ilgilidir. Örneğin, bir yedekleme sisteminde, kendisine uygulanan yamaların %100'ünü inceliyoruz. Kodun ne olduğunu biliyoruz. Ve yeni versiyonların üretime sunulmasında daha rahatız. Yani her şeyden önce özgüvenle, gelişmeye hazır olmayla ve güvenilirlikle ilgilidir.
Başka bir soru: “Yandex.Cloud'da yaşayan harici kullanıcıların gereksinimleri, dahili Cloud'da yaşayan dahili kullanıcılardan farklı mı?”
Yük profili elbette farklıdır. Ancak benim departmanım açısından tüm özel ve ilginç durumlar standart olmayan bir yük üzerinde yaratılıyor. Hayal gücüne sahip geliştiricilerin, beklenmeyeni yapan geliştiricilerin hem şirket içinde hem de şirket dışında bulunması muhtemeldir. Bu bakımdan hepimiz yaklaşık olarak aynıyız. Ve muhtemelen Yandex veritabanlarının işleyişindeki tek önemli özellik, Yandex'in içinde bir öğretinin olması olacaktır. Bir noktada bazı kullanılabilirlik alanları tamamen gölgede kalır ve buna rağmen tüm Yandex hizmetlerinin bir şekilde çalışmaya devam etmesi gerekir. Bu küçük bir farktır. Ancak veritabanı ve ağ yığınının arayüzünde çok fazla araştırma geliştirmesi yaratır. Aksi takdirde, harici ve dahili kurulumlar özellikler için aynı talepleri ve güvenilirliği ve performansı artırmaya yönelik benzer talepleri üretir.
Sonraki soru: “Yaptıklarınızın çoğunun diğer Bulutlar tarafından kullanıldığı gerçeği hakkında kişisel olarak ne düşünüyorsunuz?” Bunların isimlerini vermeyeceğiz ancak Yandex.Cloud'da yapılan projelerin çoğu başkalarının bulutlarında kullanılıyor.
Bu havalı. Öncelikle bu, bir şeyi doğru yaptığımızın göstergesidir. Ve egoyu tırmalıyor. Ve doğru kararı verdiğimizden daha eminiz. Öte yandan gelecekte bunun bize yeni fikirler, üçüncü taraf kullanıcılardan yeni talepler getireceği umudu da bu. GitHub'daki sorunların çoğu, bireysel sistem yöneticileri, bireysel DBA'lar, bireysel mimarlar, bireysel mühendisler tarafından oluşturulur, ancak bazen sistematik deneyimi olan kişiler gelir ve belirli vakaların %30'unda bu sorunu yaşadığımızı söyler ve bunu nasıl çözeceğimizi düşünelim. En çok beklediğimiz şey bu. Deneyimlerimizi diğer bulut platformlarıyla paylaşmayı sabırsızlıkla bekliyoruz.
Maraton hakkında çok konuştun. Moskova'da maraton koştuğunuzu biliyorum. Sonuç olarak? PostgreSQL'deki adamları geride mi bıraktınız?
Hayır, Oleg Bartunov çok hızlı koşuyor. Benden bir saat önce bitirdi. Genel olarak, geldiğim noktadan memnunum. Benim için bitirmek bile bir başarıydı. Genel olarak postgres topluluğunda bu kadar çok koşucunun olması şaşırtıcı. Bana öyle geliyor ki aerobik sporları ile sistem programlama isteği arasında bir tür ilişki var.
ClickHouse'da koşucu olmadığını mı söylüyorsun?
Orada olduklarından kesinlikle eminim. ClickHouse aynı zamanda bir veritabanıdır. Bu arada Oleg şimdi bana yazıyor: "Raporun ardından koşuya çıkalım mı?" Bu harika bir fikir.
Yayından Nikita'dan bir soru daha: "Greenplum'daki hatayı neden kendiniz düzelttiniz ve gençlere vermediniz?" Doğru, hatanın ne olduğu ve hangi hizmette olduğu çok açık değil, ancak muhtemelen bahsettiğiniz hata anlamına geliyor.
Evet, prensip olarak birine verilmiş olabilir. Az önce değiştirdiğim koddu. Ve bunu hemen yapmaya devam etmek doğaldı. Prensip olarak uzmanlığı ekiple paylaşma fikri iyi bir fikirdir. Greenplum görevlerini bölümümüzün tüm üyeleri arasında kesinlikle paylaşacağız.
Madem gençlerden bahsediyoruz, işte bir soru. Kişi Postgres'te ilk taahhüdü oluşturmaya karar verdi. İlk taahhütte bulunmak için ne yapması gerekiyor?
Bu ilginç bir soru: “Nereden başlamalı?” Çekirdekteki bir şeyle başlamak genellikle oldukça zordur. Örneğin Postgres'te bir yapılacaklar listesi var. Ama aslında bu onların yapmaya çalıştıkları ama başaramadıkları şeyin bir sayfasıdır. Bunlar karmaşık şeyler. Ve genellikle ekosistemde, çekirdek geliştiricilerinin daha az dikkatini çeken, geliştirilebilecek bazı yardımcı programlar, bazı uzantılar bulabilirsiniz. Ve buna göre orada büyüme için daha fazla nokta var. Postgres topluluğu her yıl Google Summer of Code programında ele alınabilecek birçok farklı konuyu öne çıkarıyor. Bu yıl sanırım üç öğrencimiz vardı. Hatta biri WAL-G'de Yandex için önemli olan konularda yazdı. Greenplum'da her şey Postgres topluluğuna göre daha basittir çünkü Greenplum bilgisayar korsanları çekme isteklerini çok iyi ele alır ve hemen incelemeye başlar. Postgres'e bir yama göndermek birkaç ay meselesi ama Greenplum bir gün içinde gelip ne yaptığınızı görecek. Bir diğer konu ise Greenplum'un mevcut sorunları çözmesi gerekiyor. Greenplum yaygın olarak kullanılmadığından sorununuzu bulmak oldukça zordur. Ve her şeyden önce elbette sorunları çözmemiz gerekiyor.
Kaynak: habr.com