Abrechnungsarchitektur der nächsten Generation: Übergang zu Tarantool

Warum rechnet ein Unternehmen wie MegaFon, Tarantool? Von außen scheint es, dass der Verkäufer normalerweise kommt, eine große Kiste mitbringt, den Stecker in die Steckdose steckt - hier kommt die Abrechnung! Früher war es so, aber jetzt ist es archaisch und solche Dinosaurier sind bereits ausgestorben oder ausgestorben. Die Abrechnung ist zunächst ein Abrechnungssystem - ein Lesegerät oder ein Taschenrechner. In der modernen Telekommunikation ist dies ein System zur Automatisierung des gesamten Lebenszyklus der Interaktion mit dem Abonnenten vom Vertragsabschluss bis zur Kündigung , einschließlich Echtzeitabrechnung, Zahlungsannahme und vielem mehr. Die Abrechnung in Telekommunikationsunternehmen ähnelt einem Kampfroboter - groß, leistungsstark und mit Waffen aufgehängt.



Und hier ist Tarantool? Oleg Ivlev und Andrey Knyazev werden darüber sprechen. Oleg ist der Chefarchitekt von MegaFon mit umfassender Erfahrung in ausländischen Unternehmen. Andrey ist der Direktor für Geschäftssysteme. Aus dem Protokoll ihres Berichts auf der Tarantool-Konferenz 2018 erfahren Sie, warum F & E in Unternehmen erforderlich ist, was Tarantool ist, wie der Stillstand für die vertikale Skalierung und Globalisierung zu den Voraussetzungen für die Entstehung dieser Datenbank im Unternehmen wurde, über technologische Herausforderungen, die Transformation der Architektur und wie MegaFons Technostek Netflix ähnelt. Google und Amazon.

Einzelabrechnungsprojekt

Das Projekt, das diskutiert wird, heißt "Single Billing". In ihm zeigte Tarantool seine besten Eigenschaften.



Das Wachstum der Leistung von Hi-End-Geräten konnte nicht mit dem Wachstum der Abonnentenbasis und der Zunahme der Anzahl der Dienste Schritt halten, ein weiteres Wachstum der Anzahl der Abonnenten und Dienste aufgrund von M2M, IoT wurde erwartet und Zweigstellenmerkmale führten zu einer Verschlechterung der Markteinführungszeit. Das Unternehmen entschied sich für ein einheitliches Geschäftssystem mit einer einzigartigen modularen Architektur von Weltklasse anstelle von 8 derzeit unterschiedlichen Abrechnungssystemen.

MegaFon besteht aus acht Unternehmen in einem . Im Jahr 2009 wurde die Umstrukturierung abgeschlossen: Niederlassungen in ganz Russland wurden zu einem einzigen Unternehmen, MegaFon OJSC (jetzt PJSC), zusammengelegt. Somit verfügt das Unternehmen über 8 Abrechnungssysteme mit eigenen „kundenspezifischen“ Lösungen, Branchenfunktionen und einer anderen Organisationsstruktur, IT und Marketing.

Alles war in Ordnung, bis ich ein gemeinsames Bundesprodukt auf den Markt bringen musste. Hier traten viele Schwierigkeiten auf: für einige, Tarifierung mit Aufrundung, für andere in geringerem Maße und für andere nach dem arithmetischen Mittel. Es gibt Tausende solcher Momente.

Trotz der Tatsache, dass die Version des Abrechnungssystems die gleiche ist, ein Lieferant, gingen die Einstellungen auseinander, so dass der Kleber für eine lange Zeit. Wir haben versucht, ihre Anzahl zu reduzieren, und sind auf ein zweites Problem gestoßen, das vielen Unternehmen bekannt ist.

Vertikale Skalierung . Selbst das kühlste Eisen zu dieser Zeit entsprach nicht den Anforderungen. Wir haben Hewlett-Packard-Geräte verwendet, die Superdome Hi-End-Linie, aber es wurden nicht einmal zwei Zweige benötigt. Ich wollte eine horizontale Skalierung ohne große Transaktionskosten und Kapitalinvestitionen.

Erwartung eines Wachstums der Anzahl der Abonnenten und Dienste . Die Berater haben lange Zeit Geschichten über IoT und M2M in die Telekommunikationswelt gebracht: Es wird eine Zeit kommen, in der jedes Telefon und Bügeleisen eine SIM-Karte und zwei im Kühlschrank haben wird. Heute haben wir eine Anzahl von Abonnenten, und in naher Zukunft wird es eine Größenordnung mehr geben.

Technologische Herausforderungen

Diese vier Gründe haben uns zu großen Veränderungen geführt. Es gab die Wahl zwischen einem Upgrade des Systems und einem Design von Grund auf neu. Sie dachten lange nach, trafen ernsthafte Entscheidungen, spielten Ausschreibungen. Infolgedessen haben sie sich von Anfang an für das Design entschieden und interessante Herausforderungen angenommen - technologische Herausforderungen.

Skalierbarkeit

Wenn es früher beispielsweise 8 Abrechnungskonten für 15 Millionen Abonnenten gegeben hätte und jetzt 100 Millionen Abonnenten und mehr hätten sich herausstellen sollen - die Last ist um eine Größenordnung höher.

Wir sind vergleichbar mit großen Internet-Playern wie Mail.ru oder Netflix.

Weitere Maßnahmen zur Erhöhung der Auslastung und der Abonnentenbasis stellten uns jedoch vor große Herausforderungen.

Die Geographie unseres riesigen Landes

Zwischen Kaliningrad und Wladiwostok 7500 km und 10 Zeitzonen . Die Lichtgeschwindigkeit ist endlich und bei solchen Verzögerungsabständen bereits signifikant. 150 ms auf den coolsten modernen optischen Kanälen sind ein bisschen viel für die Echtzeitabrechnung, insbesondere wie es jetzt in der Telekommunikation in Russland der Fall ist. Darüber hinaus müssen Sie an einem Werktag und mit unterschiedlichen Zeitzonen aktualisieren - dies ist ein Problem.

Wir bieten nicht nur Dienstleistungen gegen eine monatliche Gebühr an, wir haben komplexe Tarife, Pakete und verschiedene Modifikatoren. Wir müssen dem Teilnehmer nicht nur erlauben oder verbieten zu sprechen, sondern ihm auch eine bestimmte Quote geben - um Anrufe und Aktionen in Echtzeit zu berechnen, damit er es nicht bemerkt.

Fehlertoleranz

Dies ist die Kehrseite der Zentralisierung.

Wenn wir alle Abonnenten in einem System sammeln, sind alle Notfallereignisse und Katastrophen für das Geschäft katastrophal. Daher gestalten wir das System so, dass die Auswirkungen von Unfällen auf die gesamte Teilnehmerbasis ausgeschlossen sind.

Dies ist wiederum eine Folge der Ablehnung der vertikalen Skalierung. Bei der horizontalen Skalierung haben wir die Anzahl der Server von Hunderten auf Tausende erhöht. Sie müssen verwaltet und austauschbar sein, die IT-Infrastruktur automatisch sichern und das verteilte System wiederherstellen.

Solche interessanten Herausforderungen standen uns gegenüber. Wir haben das System entworfen und in diesem Moment versucht, die weltweit besten Praktiken zu finden, um zu überprüfen, wie sehr wir im Trend sind und wie viel wir fortschrittlichen Technologien folgen.

Welterfahrung

Überraschenderweise haben wir in der Welttelekommunikation keine einzige Referenz gefunden.

Europa sank um die Anzahl der Abonnenten und die Größenordnung, die Vereinigten Staaten - um die Ebene seiner Tarife. Wir haben uns etwas in China angesehen, aber etwas in Indien gefunden und Spezialisten von Vodafone India mitgenommen.

Zur Analyse der Architektur wurde das Dream Team unter der Leitung von IBM, Architekten aus verschiedenen Bereichen, zusammengestellt. Diese Leute könnten angemessen bewerten, was wir tun, und bestimmte Kenntnisse in unsere Architektur einbringen.

Skalieren

Ein paar Zahlen zur Veranschaulichung.

Wir entwickeln ein System für 80 Millionen Abonnenten mit einer Reserve von einer Milliarde . Also entfernen wir zukünftige Schwellenwerte. Dies liegt nicht daran, dass wir China übernehmen werden, sondern am Druck von IoT und M2M.

300 Millionen Dokumente werden in Echtzeit verarbeitet . Obwohl wir 80 Millionen Abonnenten haben, arbeiten wir mit potenziellen Kunden und denen, die uns verlassen haben, zusammen, wenn wir Forderungen einziehen müssen. Daher sind die realen Volumina viel größer.

Täglich ändern 2 Milliarden Transaktionen den Kontostand - dies sind Zahlungen, Gebühren, Anrufe und andere Ereignisse. 200 TB Daten ändern sich aktiv , 8 PB Daten ändern sich etwas langsamer, und dies ist kein Archiv, sondern Live-Daten in einer einzigen Abrechnung. Die Skalierung des Rechenzentrums umfasst 5.000 Server an 14 Standorten .

Technologie-Stack

Als wir die Architektur planten und mit der Montage des Systems begannen, importierten wir die interessantesten und fortschrittlichsten Technologien. Das Ergebnis war ein technologischer Stack, der jedem Internet-Player und Unternehmen, die hoch ausgelastete Systeme herstellen, vertraut ist.



Der Stack ähnelt den Stacks anderer Hauptakteure: Netflix, Twitter, Viber. Es besteht aus 6 Komponenten, aber wir wollen es reduzieren und vereinheitlichen.

Flexibilität ist gut, aber in einem großen Unternehmen gibt es keinen Weg ohne Vereinigung.

Wir werden nicht dasselbe Oracle in Tarantool ändern. In der Realität großer Unternehmen ist dies eine Utopie oder ein Kreuzzug für 5-10 Jahre mit einem unverständlichen Ergebnis. Aber Cassandra und Couchbase können durch Tarantool ersetzt werden, und wir fühlen uns dem verpflichtet.

Warum Tarantool?

Es gibt 4 einfache Kriterien, warum wir diese Datenbank ausgewählt haben.

Geschwindigkeit . Wir haben Stresstests an MegaFon-Industriesystemen durchgeführt. Tarantool gewann - es zeigte die beste Leistung.

Dies bedeutet nicht, dass andere Systeme die Anforderungen von MegaFon nicht erfüllen. Aktuelle Speicherlösungen sind so produktiv, dass dieser Bestand des Unternehmens mehr als ausreichend ist. Wir sind jedoch daran interessiert, mit dem Anführer umzugehen, und nicht mit demjenigen, der den Schwanz einwebt, einschließlich des Belastungstests.

Tarantool deckt auch langfristig die Bedürfnisse des Unternehmens ab.

TCO-Kosten . Die Unterstützung von Couchbase auf MegaFon-Volumes kostet Platz, mit Tarantool ist die Situation viel besser und in Bezug auf die Funktionalität sind sie eng.

Eine weitere nette Funktion, die unsere Wahl leicht beeinflusst hat - Tarantool funktioniert besser als andere Datenbanken mit Speicher. Es zeigt maximale Effizienz .

Zuverlässigkeit MegaFon investiert in Zuverlässigkeit, wahrscheinlich wie kein anderer. Als wir uns Tarantool anschauten, stellten wir fest, was zu tun ist, damit es unseren Anforderungen entspricht.

Wir haben unsere Zeit und Finanzen investiert und zusammen mit Mail.ru eine Unternehmensversion erstellt, die jetzt von mehreren anderen Unternehmen verwendet wird.

Tarantool-Enterprise hat uns mit Sicherheit, Zuverlässigkeit und Protokollierung voll zufrieden gestellt.

Partnerschaft

Das Wichtigste für mich ist der direkte Kontakt zum Entwickler . Genau das haben die Tarantool-Leute bestochen.

Wenn Sie zu einem Spieler kommen, insbesondere zu einem, der mit einem Anker-Client arbeitet, und sagen, dass Sie die Datenbank benötigen, um dies, dies und das zu können, antwortet sie normalerweise:

- Nun, legen Sie die Anforderungen unter den Boden dieses Stapels - eines Tages werden wir sie wahrscheinlich erreichen.

Viele haben eine Roadmap für die nächsten 2-3 Jahre, und es ist fast unmöglich, sie dort zu integrieren, und Tarantool-Entwickler bestechen mit Offenheit und nicht nur mit MegaFon und passen ihr System an den Kunden an. Das ist cool und wir mögen es wirklich.

Wo haben wir Tarantool angewendet?

Bei uns wird Tarantool in mehreren Elementen verwendet. Der erste ist im Pilotprojekt , das wir im Adressverzeichnissystem erstellt haben. Früher wollte ich, dass es ein System ist, das Yandex.Maps und Google Maps ähnelt, aber es stellte sich etwas anders heraus.

Zum Beispiel das Adressverzeichnis in der Verkaufsschnittstelle. Unter Oracle dauert das Finden der benötigten Adresse 12-13 Sekunden. - unangenehme Zahlen. Wenn wir zu Tarantool wechseln, Oracle durch eine andere Datenbank in der Konsole ersetzen und dieselbe Suche durchführen, erhalten wir eine 200-fache Beschleunigung! Die Stadt taucht nach dem dritten Buchstaben auf. Jetzt passen wir die Oberfläche so an, dass dies nach dem ersten geschieht. Die Reaktionsgeschwindigkeit ist jedoch völlig anders - bereits Millisekunden statt Sekunden.

Die zweite Anwendung ist ein Trendthema namens Two-Speed-IT . Dies liegt daran, dass Berater aus jedem Eisen sagen, dass Unternehmen dorthin gehen sollten.



Es gibt eine Infrastrukturschicht, Domänen darüber, z. B. ein Abrechnungssystem wie Telekommunikation, Unternehmenssysteme und Unternehmensberichte. Dies ist der Kern, der nicht berührt werden muss. Das ist natürlich möglich, aber paranoid in der Bereitstellung von Qualität, weil es dem Unternehmen Geld bringt.

Als nächstes kommt die Schicht der Mikrodienste - die, die den Bediener oder einen anderen Spieler unterscheidet. Auf der Grundlage bestimmter Caches können schnell Microservices erstellt werden, die Daten aus verschiedenen Domänen abrufen. Hier ist ein Feld für Experimente - wenn etwas nicht geklappt hat, einen Microservice geschlossen, einen anderen geöffnet. Dies bietet eine wirklich verlängerte Markteinführungszeit und erhöht die Zuverlässigkeit und Geschwindigkeit des Unternehmens.

Microservices ist vielleicht die Hauptrolle von Tarantool in MegaFon.

Wo wir Tarantool anwenden wollen

Wenn wir unser erfolgreiches Abrechnungsprojekt mit Transformationsprogrammen bei der Deutschen Telekom, Svyazkome, Vodafone India vergleichen, ist es überraschend dynamisch und kreativ. Bei der Implementierung dieses Projekts wurden nicht nur MegaFon und seine Struktur verändert, sondern auch Tarantool-Enterprise erschien bei Mail.ru, und unser Anbieter Nexign (ehemals Peter-Service) verfügte über eine BSS-Box (Boxed Billing Solution).

In gewisser Hinsicht ist dies ein historisches Projekt für den russischen Markt. Es kann mit dem verglichen werden, was im Buch von Frederick Brooks „Mythical Man-Month“ beschrieben ist. In den 60er Jahren zog IBM 5.000 Mitarbeiter an, um ein neues OS / 360-Betriebssystem für Mainframes zu entwickeln. Wir haben weniger als 1.800, aber unsere sind in Westen, und unter Berücksichtigung des Einsatzes von Open Source und neuer Ansätze arbeiten wir produktiver.

Die Abrechnungsdomänen oder allgemeiner die Geschäftssysteme werden unten angezeigt. Mitarbeiter kennen CRM sehr gut. Jeder sollte bereits andere Systeme haben: Open API, Gateway API.

API öffnen

Schauen wir uns noch einmal die Zahlen an und wie die Open API jetzt funktioniert. Die Last beträgt 10.000 Transaktionen pro Sekunde . Da wir planen, die Microservice-Schicht aktiv zu entwickeln und die öffentliche MegaFon-API zu erstellen, erwarten wir in diesem speziellen Teil in Zukunft mehr Wachstum. 100.000 Transaktionen werden definitiv sein .

Ich weiß nicht, ob das SSO mit Mail.ru vergleichbar ist - die Jungs haben beispielsweise 1.000.000 Transaktionen pro Sekunde. Wir sind sehr an ihrer Lösung interessiert und planen, aus ihren Erfahrungen zu lernen - zum Beispiel, um mit Tarantool eine funktionierende SSO-Reserve zu bilden. Jetzt machen Entwickler von Mail.ru dies mit uns.

CRM

CRM - das sind genau 80 Millionen Abonnenten, die wir auf eine Milliarde bringen möchten, da es bereits 300 Millionen Dokumente gibt, die eine dreijährige Geschichte enthalten. Wir freuen uns sehr auf neue Dienste, und hier ist der Wachstumspunkt vernetzte Dienste . Dies ist ein Ball, der wachsen wird, weil es immer mehr Dienste geben wird. Dementsprechend wird eine Geschichte benötigt, über die wir nicht stolpern wollen.

Die Abrechnung in Bezug auf die Abrechnung und die Arbeit mit den Forderungen der Kunden wurde in eine separate Domäne umgewandelt . Um die Leistung zu maximieren, wird die Architekturvorlage für die Domänenarchitektur angewendet .

Das System ist in Domänen unterteilt, die Last wird verteilt und Fehlertoleranz bereitgestellt. Zusätzlich haben wir mit verteilter Architektur gearbeitet.

Alles andere sind Lösungen auf Unternehmensebene. Im Call Store - 2 Milliarden pro Tag , 60 Milliarden pro Monat. Manchmal muss man sie einen Monat lang und besser schnell nacherzählen. Die Finanzüberwachung ist genau die 300 Millionen, die ständig wachsen und wachsen: Abonnenten wechseln häufig zwischen Betreibern und erhöhen diesen Anteil.

Die Telekommunikationskomponente der Mobilkommunikation ist die Online-Abrechnung . Dies sind die Systeme, mit denen Sie anrufen oder nicht anrufen können, um in Echtzeit eine Entscheidung zu treffen. Hier beträgt die Last 30.000 Transaktionen pro Sekunde. Angesichts des wachsenden Datenübertragungsplans planen wir 250.000 Transaktionen und sind daher sehr an Tarantool interessiert.

Das vorherige Bild zeigt die Domänen, in denen wir Tarantool verwenden werden. CRM selbst ist natürlich breiter und wir werden es im Kern selbst anwenden.

Unsere geschätzte TTX von 100 Millionen Abonnenten verwirrt mich als Architekt - was ist, wenn 101 Millionen? Alles noch einmal wiederholen? Um dies zu verhindern, verwenden wir Caches und erhöhen gleichzeitig die Zugänglichkeit.



Im Allgemeinen gibt es zwei Ansätze zur Verwendung von Tarantool. Der erste besteht darin, alle Caches auf der Microservice-Ebene zu erstellen . Soweit ich weiß, folgt VimpelCom diesem Pfad und erstellt einen Client-Cache.

Wir sind weniger abhängig von Anbietern, wir ändern den Kern von BSS, sodass wir sofort eine einzige Client-Kartei haben. Aber wir wollen es sticken. Daher verwenden wir einen etwas anderen Ansatz - wir erstellen Caches innerhalb der Systeme .

Es gibt also weniger als einen Rassynchron - ein System ist sowohl für einen Cache als auch für die Hauptmasterquelle verantwortlich.

Das Verfahren passt gut zum Tarantool-Transaktionsskelett-Ansatz, wenn nur Teile aktualisiert werden, die sich auf Aktualisierungen beziehen, d. H. Datenänderungen. Alles andere kann woanders aufbewahrt werden. Es gibt keinen riesigen Datensee, keinen nicht verwalteten globalen Cache. Caches sind für das System konzipiert, entweder für Produkte oder für Kunden, oder um dem Service das Leben zu erleichtern. Wenn ein Abonnent aufgrund seiner Qualität verärgert anruft, möchte ich ihn qualitativ bedienen.

RTO und RPO

Es gibt zwei Begriffe in IT - RTO und RPO .

Das Ziel der Wiederherstellungszeit ist die Zeit, um einen Dienst nach einem Fehler wiederherzustellen. RTO = 0 bedeutet, dass der Dienst auch dann weiter funktioniert, wenn etwas herunterfällt.

Ziel des Wiederherstellungspunkts ist die Zeit für die Wiederherstellung von Daten, wie viele Daten wir über einen bestimmten Zeitraum verlieren können. RPO = 0 bedeutet, dass wir keine Daten verlieren.

Tarantool Herausforderung

Versuchen wir, das Problem für Tarantool zu lösen.

Gegeben : Jeder versteht den Anwendungskorb, zum Beispiel bei Amazon oder anderswo. Der Korb muss 24 Stunden, 7 Tage die Woche oder 99,99% der Zeit arbeiten. Bestellungen, die bei uns eingehen, müssen in Ordnung bleiben, da wir die Kommunikation für den Abonnenten nicht zufällig aktivieren oder deaktivieren können - alles muss streng konsistent sein. Das vorherige Abonnement wirkt sich auf das nächste aus, daher sind die Daten wichtig - nichts sollte verloren gehen.

Lösung . Sie können versuchen, es direkt zu lösen und die Entwickler der Datenbank fragen, aber das Problem ist mathematisch nicht gelöst. Man kann sich an Theoreme, Erhaltungssätze, Quantenphysik erinnern, aber warum - es kann nicht auf DB-Ebene gelöst werden.

Der gute alte architektonische Ansatz funktioniert hier - Sie müssen den Themenbereich gut kennen und auf seine Kosten diesen Rebus lösen.



Unsere Lösung: Erstellen Sie ein verteiltes Anwendungsregister für Tarantool - einen geoverteilten Cluster . In der Abbildung sind dies drei verschiedene Rechenzentren - zwei für den Ural und eines für den Ural. Wir verteilen alle Anwendungen an diese Zentren.

Netflix, das heute als einer der führenden IT-Anbieter gilt, verfügte bis 2012 nur über ein Rechenzentrum. Am Vorabend der katholischen Weihnacht am 24. Dezember fiel dieses Rechenzentrum aus. Benutzer von Kanada und den Vereinigten Staaten blieben ohne ihre Lieblingsfilme, sehr verärgert und schrieben darüber in sozialen Netzwerken. Netflix verfügt nun über drei Rechenzentren an der Westostküste und eines in Westeuropa.

Wir bauen zunächst eine geoverteilte Lösung - Fehlertoleranz ist uns wichtig.

Wir haben also einen Cluster, aber was ist mit RPO = 0 und RTO = 0? Die Lösung ist einfach, was vom Thema abhängt.

Was ist bei Anwendungen wichtig? Zwei Teile: Werfen Sie den Korb, bevor Sie eine Kaufentscheidung treffen, und danach. Ein Teil von DO in einer Telekommunikation wird normalerweise als Auftragserfassung oder Auftragsverhandlung bezeichnet . In der Telekommunikation kann dies viel komplizierter sein als im Online-Shop, da Sie dort den Kunden bedienen, 5 Optionen anbieten müssen, und dies alles geschieht für eine Weile, aber der Warenkorb ist voll. Zu diesem Zeitpunkt ist ein Fehler möglich, aber nicht beängstigend, da er in einem interaktiven Modus unter der Aufsicht einer Person auftritt.

Wenn das Moskauer Rechenzentrum plötzlich ausfällt und automatisch zu einem anderen Rechenzentrum wechselt, werden wir weiterarbeiten. Theoretisch kann ein Produkt in einem Warenkorb verloren gehen, aber Sie sehen dies, ergänzen den Warenkorb erneut und arbeiten weiter. In diesem Fall ist RTO = 0.

Gleichzeitig gibt es eine zweite Option: Wenn wir auf "Senden" geklickt haben, möchten wir, dass die Daten nicht verloren gehen. Ab diesem Moment beginnt die Automatisierung zu funktionieren - dies ist bereits RPO = 0. Die Anwendung dieser beiden unterschiedlichen Muster kann in einem Fall nur ein geoverteilter Cluster mit einem umschaltbaren Master sein, in dem anderen Fall eine Art Quorumeintrag. Muster können variieren, aber wir lösen das Problem.

Mit einem verteilten Anwendungsregister können wir auch alles skalieren - um viele Disponenten und Auftragnehmer zu haben, die auf dieses Register zugreifen.

Cassandra und Tarantool zusammen

Es gibt noch einen anderen Fall - das "Schaufenster der Waagen". Hier ist nur ein interessanter Fall der gemeinsamen Verwendung von Cassandra und Tarantool.

Wir verwenden Cassandra, weil 2 Milliarden Anrufe pro Tag nicht das Limit sind und es mehr geben wird. Vermarkter lieben es, den Verkehr nach Quellen zu färben. In sozialen Netzwerken gibt es zum Beispiel immer mehr Details. Dies alles erhöht die Geschichte.

Mit Cassandra können Sie horizontal auf jedes Volumen skalieren.

Wir fühlen uns wohl mit Cassandra, aber sie hat ein Problem - sie kann nicht gut lesen. , 30 000 — .

, : , - , Cassandra. , IBM manager file transfer — , , UDP, , TCP. , , , - , — .

, . Kafka Tarantool, , , , , , , 100 2 .

, 2 , , .

Fazit

Tarantool. Mail.ru, .

BCG McKinsey, Accenture IBM - — , , , , . , Tarantool . .

— Tarantool Conference , 17 T+ Conference 2019 « Tarantool Enterprise» . « Tarantool Oracle» . , , . — , . : , Tarantool, , , .