Gini'nin Veritabanı Motoru Nedir?

There's a lot of hype and confusion swirling around database engine technologies today. The hype is often caused by the following factors:

• Kar amacı gütmeyen kuruluşlar bize bir şeyler satmaya çalışırken teknik medya alanına propaganda yapıyorlar.
• Mühendisler zamanlarını ve enerjilerini öğrenmeye harcadıkça, sıklıkla teknolojilerde ortaya çıkan kabile zihniyeti. Bu, mühendislerin öznel, kişisel nedenlerden dolayı teknolojilere duygusal ve finansal bağlar geliştirmelerine neden olabilir.
• Teknolojiler, hızla gelişen teknik zorlukların üstesinden gelmek için yeni özellikler ve yeni yöntemler ile sürekli gelişmektedir. İnovasyonun hızlı hızı doğal olarak kafa karıştırıcı olabilir.

Tüm bu faktörleri göz önünde bulundurduk, çünkü en iyi veritabanı motorunu düşündük. Gini BlockGrid.

Teknik açıdan bakıldığında, çeşitli veritabanı depolama modellerini temel alan birçok veritabanı altyapısı vardır. Var NoSQL veritabanı motorları, örneğin, anahtar-değer depo motorları (örneğin, LMDB, LevelDB, RocksDB, Redis, Cassandra, vb.), nesne veritabanı motorları (örneğin, MongoDB, CouchDB, DynamoDB, vb.), grafik veritabanı motorları (örneğin, Neo4j) , HyperGraphDB, vb.). Sonra SQL veritabanı motorları var (örneğin, MySQL, SQL Server, Postgres, SQLite, MariaDB, Oracle, vb.)

To understand and appreciate why a particular database engine should be used for a particular use-case, it's important to understand your domain, your goals, and the fundamental differences between each database engine. Without a deep understanding of these factors, it's too easy to be distracted by all the hype and confusion.

Gini için, çok açık bir gereksinimimiz var ve bir şifreleme para biriminin ne yapması gerektiğine dair derin bir anlayışa sahibiz. Neredeyse herkes Gini takımı Özellikle ödeme işleme hizmetleri için yüksek performanslı, kritik görev uygulamaları için veritabanlarını uygulamada yılların deneyimine sahiptir. Bu nedenle, bu soruya çok fazla içgörü ve deneyim getiriyoruz.

Yüksek düzeyde, öncelikli hedeflerimiz şunlardı:

• Cryptocurrency işlemleri olmalı birtomic, C, onsistent bensolated ve Durable ("ASİT"). We've seen many cryptocurrency projects (including many of the largest projects) ignore this fundamental principle. For the sake of maximizing teorik hız ve basitlik, diğer projeler genellikle yüksek teorik hıza sahip NoSQL veritabanı motorlarını kullanır, ancak gerçekten ACID işlemleri yapmazlar. Bu, senkronizasyon dışı veriler, DB ve dosya sistemi bozulması, basamaklama hataları ve kesintiler dahil olmak üzere uzun vadede her türlü sorunu yaratabilir; bunların tümü bilgisayar korsanlarına karşı savunmasız, zaman ve para kaybına neden olabilir.
• Yeterince yüksek Üretilen. Virtually all modern SQL and NoSQL database engines today can perform tens of thousands of read/write operations per second. This is more than sufficient for all payment networks on Earth today. For example, Visa's global credit card payment network operates at between 14,000 - 20,000 transactions per second, depending upon how it's measured. This is relatively low compared to the throughput of virtually all modern database engines today. There's no point in saying, "My DB engine is faster than yours!" if all that teorik hıza gerçekten ACID işlemi eşlik etmez, özellikle Tüm bu hız yine de gerekli değilse.
• Küçük Bellek Ayak İzi. A database engine that is a memory hog puts a strain on users' computers, which hurts the user experience and can limit broad-based adoption.
• Gömülü Tasarım. Uygulamanıza bir bileşen olarak gömülebilen bir DB motoru genellikle bilgisayarınızda çalışan tamamen ayrı programlar arasında iletişim kurması gerekenden çok daha hızlıdır. Bu nedenle gömülebilir DB motorları bu durumda idealdir.
•  İçin güvenilir Arayüz Haskell. Given that Haskell is the ideal language for building a secure, fast and scalable cryptocurrency, the DB engine must enable us to write native Haskell code that can communicate directly with the DB engine. We don't want to depend on (pseudo-) SQL code in our application logic because that slows down the DB query operations and creates friction in our development process due to frequent language context-switching.
• Kanıtlanmış Güvenilirlik Tarihi. DB motoru olmamalıdır blokta yeni çocuk. Gerçek dünyadaki görev kritik uygulamalardan en az 10 yıl bağımsız olarak doğrulanabilir performans ölçütüne sahip olmalıdır.

Buna karşılık, sık sık olarak lanse edilen aşağıdaki DB motor özellikleri gerekli birçoğunda merkezileşmiş sunucu mimarileri kesinlikle gerekli değil için Gerçekten merkezi olmayan Gini gibi cryptocurrency.

• Yüksek Eşzamanlılık. Bir için gerçekten merkezi olmayan cryptocurrency, at the DB engine level, there's usually only one (possibly a few) users accessing the DB at any given moment. This is because, in a Merkezi olmayan cryptocurrency, her düğümün blok zincirinin kendi kopyası vardır. Bu, blockchain'in yaşadığı bilgisayarda çalışan DB motorunun, yalnızca herhangi bir modern DB motoru için önemsiz olan bir veya birkaç eşzamanlı bağlantıyı kullanması gerektiği anlamına gelir. Bu, karşılaştırıldığında çok farklı bir gereksinimdir. merkezileşmiş DB motorlarının yüzlerce veya binlerce eşzamanlı DB bağlantısını gerçekleştirmesi gereken ödeme sistemleri. (Not: Bir şifreleme para birimi tam düğüm konsensüs protokolü sürecinde birçok eşzamanlı bağlantıyı yönetmeye ihtiyaç duyuyor, but that's an uygulama mantığı gereklilik, değil bir DB motor gereksinimi. Tamamen ayrı gereksinimleri olan tamamen ayrı süreçlerdir.)
• Büyük Veri Yetenekleri. İnsanlar sık sık konuşurlar Büyük veri without actually defining what that means. DB engines like MongoDB are wonderful Big Data DB engines, but they're totally unnecessary for any decentralized blockchain. This is because "Big Data" typically means a database of at least 100 terabytes. For context, Bitcoin's database is only about 200 gigabayt in early 2019 and it's already çok büyük çünkü bu boyutta bir DB, giderek daha az sayıda kullanıcının tüm blok zincirini indirebildiğinden doğal ağ merkezileşmesine neden olmaya başlar. Böylece, ulaşmak istediğiniz herhangi bir kripto para birimi ekibi gerçekten merkezi olmayan architecture must build pruning, snapshotting and multiple node types into their architecture. Regardless, a blockchain is useless long before it ever reaches the minimum "Big Data" size of 100 terabytes.

Ölçeklenebilirlik

Genel olarak iki tür veritabanı ölçeklenebilirliği vardır: dikey ölçeklenebilirlik (yani, bir saniyedeki kaç işlem tek bir DB motoru yapabilir) ve yatay ölçeklenebilirlik (saniyede kaç adet işlem yapabilir bir küme of DB engines process). Given that we are talking about a decentralized network, the concept of "vertical scaling" is not very relevant for the reasons stated in the "High Enough Throughput" section above. So, we will focus on horizontal scaling below.

Yatay Gerçekten merkezi olmayan bir şifreleme para birimi için ölçeklenebilirlik, herhangi bir modern DB motoru tarafından asla kısıtlanmayacaktır. Örneğin, SQLite herhangi bir büyük ölçekli ödeme ağı için yeterince hızlı olan emtia donanımında saniyede en az 50.000 ekleme işlemi gerçekleştirebilir bugün. (But it's not fast enough for IoT- and AI-driven payment networks in the future, which is why we are also working on adding more horizontal scaling features to Gini for the future.) Here are a few points regarding horizontal scalability.

• DB motor hızı / veriminden bağımsız olarak, Gerçekten merkezi olmayan cryptocurrency will always be constrained by the consensus protocol due to the requirement of syndicating blocks across the network to the minimum quorum of nodes. Here, the speed of light and network conditions are the constraints. Thus, most of the work related to achieving horizontal scalability needs to be performed in a blockchain node's application logic, regardless of the underlying DB engine.

• Bir şifreleme para birimi için yatay ölçeklenebilirlik elde etmenin tek gerçekçi yolu, iş yükü paylaşma, ödeme kanalı tünelleme ve ağ topolojisi bölümlemesinin birleşimidir. (DB motoru gerçekten darboğaz olmadığında yalnızca DB paylaşması hiçbir şey yapmaz.) Tabii ki, bu teknikler bazı paydaşların belirli pazar segmentleri için, örneğin IoT, yüksek hacimli için kabul edebileceği bir tradeof olan ağa bir merkezileşme getirdi. finansal hizmetler ve yüksek hızlı / verim gerektiren veri bilimi uygulamaları.

MongoDB gibi NoSQL DB motorları bir kümedeki tüm düğümler aynı aralık içinde çalıştığında en değerlidir merkezileşmiş ağ altyapısı ve merkezi olmayan bir fikir birliği protokolünün ek yükü olmadan; Aksi halde değerleri Postgress veya SQLite gibi SQL tabanlı bir DB motorundan çok daha iyi veya daha kötü değildir. Aslında, için gerçekten merkezi olmayan Gini gibi kripto para birimleri, seçim çoğunlukla kişisel tercihlere ve araçlara dayalıdır, örneğin, eğer bir kişi koleksiyonları / nesneleri vs. tablolar / satırlar ve JSON-SQL'i tercih ederse ve tasarımın karmaşıklığını azaltan bir dil tarafından sağlanan arayüzler olup olmadığını DB sorgularını optimize etmek.

Bütün bu nedenlerden dolayı, Gini BlockGrid için, çok sağlam ve hızlı olanları seçtik SQLite veritabanı motoruDünyadaki en zorlu hesaplama ortamlarında yaklaşık yirmi yıldır kanıtlanmış ve güvenilir.