alfa 卡王

A still from «Our Secret Universe: The Hidden Life of the Cell»《我们的秘密宇宙：细胞的隐秘生命》一书
Investment business is one of the most complex domains in the banking world. It's about not just credits, loans, and deposits — there are also securities, currencies, commodities, derivatives, and all kinds of complex stuff like structured products.
投资业务是银行界最复杂的领域之一。 它不仅涉及信贷，贷款和存款，还涉及证券，货币，商品，衍生品以及各种复杂的东西，例如结构性产品。
Recently, people have become increasingly aware of their finances. More and more get involved in securities trading. Individual investment accounts have emerged not so long ago. They allow you to trade in securities and get tax credits or avoid taxes at the same time. All clients coming to us want to manage their portfolios and see their reporting on-line. Most frequently, these are multi-product portfolios, which means that people are clients of different business areas.
最近，人们越来越意识到自己的财务状况。 越来越多的人参与证券交易。 个人投资账户不久前就出现了。 它们使您可以交易证券并同时获得税收抵免或避免税收。 所有来我们这里的客户都希望管理他们的投资组合，并在线查看他们的报告。 最常见的是，这些是多产品组合，这意味着人员是不同业务领域的客户。
Moreover, the demands of regulators, both Russian and international, also grow.
此外，俄罗斯和国际监管机构的需求也在增长。
To meet the current needs and lay a foundation for future upgrades, we've developed our Tarantool-based investment business core.
为了满足当前的需求并为将来的升级奠定基础，我们开发了基于Tarantool的投资业务核心。
A few statistics: Alfa Bank's investment business provides brokerage services to individuals and entities enabling them to trade in various securities markets; custody services holding their securities; trust management services for big private capital owners, and securities emission services to other companies. Talking about Alfa Bank's investment business, we mean over 3 thousand quotations per second which come from different trading platforms. Over 300 thousand transactions per trading day are closed on behalf of the bank or its clients. There are up to 5 thousand orders executed every second on domestic and international platforms. On top of that, all clients, both domestic and international, want to see their positions in real-time.
一些统计数据：阿尔法银行的投资业务为个人和实体提供经纪服务，使他们能够在各种证券市场中交易； 持有证券的托管服务； 为大型私人资本所有者提供信托管理服务，并为其他公司提供证券发行服务。 谈到阿尔法银行的投资业务，我们的意思是每秒来自不同交易平台的报价超过三千。 每个交易日代表银行或其客户完成的交易超过30万笔。 在国内和国际平台上，每秒执行多达5000笔订单。 最重要的是，所有国内外客户都希望实时查看其位置。

背景 (Background)

Starting from the early 2000s, our investment businesses are developing independently: exchange business, brokerage services, currency trading, and over-the-counter trading in securities and various derivatives. As a result, we got into the pitfall of functional wells. What is it? Each business area has its systems that duplicate each other's functions. Each system has its own data model, although they use one and the same concepts: transactions, instruments, counterparties, quotations, and others. As each system has developed independently, a diverse «technology zoo» has emerged.
从2000年代初开始，我们的投资业务开始独立发展：交易所业务，经纪服务，货币交易以及证券和各种衍生产品的场外交易。 结果，我们陷入了功能井的陷阱。 它是什么？ 每个业务领域都有其系统，这些系统可以复制彼此的功能。 每个系统都有自己的数据模型，尽管它们使用一个相同的概念：交易，工具，交易对手，报价等。 随着每个系统的独立开发，出现了一个多样化的“技术动物园”。
Additionally, the systems' codebase has become rather old, because some products were conceived back in the mid-1990s. This deterred the development process, and there were performance issues.
此外，由于某些产品是在1990年代中期构思出来的，因此系统的代码库已变得相当古老。 这阻碍了开发过程，并且存在性能问题。

新解决方案的要求 (Requirements for a new solution)

Those in the business realized that a technology transformation was vital for continued growth. We were assigned the following tasks:
业内人士意识到，技术改造对于持续增长至关重要。 我们被分配了以下任务：

1. Collect all business data in a single fast storage and within a single data model.
   在单个快速存储中和单个数据模型中收集所有业务数据。
2. The data should not be lost or modified.
   数据不应丢失或修改。
3. The data had to be versioned because the regulator could request historical data for past years at any time.
   数据必须进行版本管理，因为监管机构可以随时索取过去几年的历史数据。
4. We had not just to create some new fancy database management system but to make a platform for delivering on business objectives.
   我们不仅要创建一些新的高级数据库管理系统，而且要建立一个实现业务目标的平台。

Apart from that, our architects named their own terms:
除此之外，我们的建筑师命名了自己的术语：

1. The new solution should be enterprise-class, which means it should have been already proven in a major business.
   新解决方案应该是企业级的，这意味着它应该已经在主要业务中得到证明。
2. The solution's operation should be mission-critical. This means we should be present in several data centers at the same time and safely survive the shutdown of a single data center.
   解决方案的操作应该是关键任务。 这意味着我们应该同时出现在多个数据中心中，并在单个数据中心关闭后安全地生存下来。
3. The system should be horizontally scalable. In fact, all our current systems are only vertically scalable, and we already have no room for further growth due to low rates of hardware performance enhancement. So, we are now at the point where we need to have a horizontally scalable system to survive.
   该系统应该是水平可伸缩的。 实际上，我们当前所有的系统都只能垂直扩展，并且由于硬件性能提升的速度较低，我们已经没有进一步增长的空间。 因此，现在我们需要一个水平可扩展的系统才能生存。
4. Apart from that, we were told that the solution should be cost-efficient.
   除此之外，我们还被告知该解决方案应具有成本效益。

We followed a standard approach: specified the requirements and contacted our procurement unit. From them, we received a list of companies that generally agreed to do that for us. We told them all about the assignment and received solution quotations from six of them.
我们遵循标准方法：指定要求并联系我们的采购部门。 从他们那里，我们收到了一些公司的清单，这些公司普遍同意为我们这样做。 我们告诉了他们所有关于任务的信息，并从其中六个人那里收到了解决方案的报价。
We in the banking business take no one's word for anything and like to test everything ourselves. Thus, it was a prerequisite for the bidders to pass load tests. We specified load testing assignments, and three companies of six agreed to implement a prototype solution for their own account on the basis of in-memory technology for testing.
我们从事银行业务的人一言不发，喜欢自己测试一切。 因此，这是投标人通过负荷测试的前提。 我们指定了负载测试任务，并且有六家公司中的三家同意在内存测试技术的基础上为其自己的帐户实施原型解决方案。
I won't tell here how we were testing everything and how much time it took, just the final result: a prototype Tarantool-based solution from Mail.ru Group's developers’ team showed the best performance in loading tests. We signed a contract and started development. There were four developers from Mail.ru Group and three from Alfa Bank, three system analysts, a solution architect, a product owner, and a Scrum master.
我不会在这里告诉我们我们如何测试所有东西以及花费多少时间，而只是最终结果：来自Mail.ru Group开发人员团队的基于Tarantool的原型解决方案在加载测试中表现出最佳性能。 我们签订了合同并开始开发。 Mail.ru Group有四名开发人员，Alfa Bank有三名开发人员，三名系统分析师，解决方案架构师，产品所有者和Scrum管理员。
Now I'm going to tell you how our system grew and evolved, and what we did, and why.
现在，我将告诉您我们的系统如何成长和发展，我们做了什么以及为什么。

发展历程 (Development)

First, we asked ourselves a question about how to retrieve data from our current systems. We concluded that HTTP was quite suitable because all the current systems communicated with each other sending XML or JSON via HTTP.
首先，我们问自己一个关于如何从当前系统中检索数据的问题。 我们得出的结论是HTTP非常适合，因为当前的所有系统都通过HTTP发送XML或JSON相互通信。
We use an HTTP server built into Tarantool because we have no need to terminate SSL sessions — its capacity is more than enough.
我们使用内置于Tarantool中的HTTP服务器，因为我们无需终止SSL会话-它的容量已足够。
As I already said, all our systems exist in different data models, and, at the input, we need to bring the object to the model that we specify for us. We needed a language enabling data conversion. We chose imperative Lua. We execute all the code for data conversion in a sandbox — it's a safe place from which the running code cannot escape. To do that, we simply make a load string of the desired code, creating an environment with features that cannot block or disrupt anything.
正如我已经说过的，我们所有的系统都存在于不同的数据模型中，在输入时，我们需要将对象带到我们为我们指定的模型中。 我们需要一种支持数据转换的语言。 我们选择了命令式Lua。 我们在沙盒中执行所有用于数据转换的代码-这是一个安全的地方，正在运行的代码无法逃脱。 为此，我们只需创建所需代码的加载字符串，即可创建一个环境，该环境具有无法阻止或破坏任何内容的功能。
After conversion, data needs to be checked for conformity to the model we are creating. We had a long discussion of what the model should look like, and what language to use to define it. Our final choice was Apache Avro because it is a simple language supported by Tarantool. New versions of the model and custom code can be sent to operation several times a day, load or no load, round the clock, and we can adjust to changes really fast.
转换后，需要检查数据是否符合我们正在创建的模型。 我们讨论了模型的外观，以及定义模型所用的语言。 我们的最终选择是Apache Avro，因为它是Tarantool支持的一种简单语言。 新版本的模型和自定义代码可以一天24次发送，每天24次加载或不加载，我们可以快速调整以适应变化。
After checking, the data needs to be saved. We do this using vshard (we have geographically dispersed replica shards).
检查后，需要保存数据。 我们使用vshard来做到这一点(我们在地理位置上分散了副本碎片)。
What is special about this is that most systems that send data to us don't care if we receive the data or not. So we implemented a repair queue in the very beginning. What is it? If for some reason, an object has not passed data conversion or check, we confirm receipt anyway but save the object in the repair queue. It is coherent and is located in basic storage with business data. We wrote the admin interface, various metrics, and alerts for it early on. As a result, we don't lose data. Even if something changes in the source, if data model changes, we can notice this at once and adjust accordingly.
这样做的特殊之处在于，大多数向我们发送数据的系统都不关心我们是否接收到数据。 因此，我们从一开始就实施了维修队列。 它是什么？ 如果由于某种原因某个对象未通过数据转换或检查，我们仍然会确认已收到，但将对象保存在维修队列中。 它是一致的，位于具有业务数据的基本存储中。 我们在早期编写了管理界面，各种指标和警报。 因此，我们不会丢失数据。 即使源发生了某些变化，如果数据模型发生了变化，我们也可以立即注意到并进行相应调整。
Now we have to learn how to retrieve the saved data. We gave our systems a thorough review and saw that on a classic stack from Java and Oracle there was always some ORM that converted relational data to object data. So why not just feed objects to systems in the form of a graph? That is why we gladly chose GraphQL which satisfied our needs. It enables data to be obtained in the form of graphs and retrieve only what is needed at the moment. Even API can be versioned with sufficient flexibility.
现在我们必须学习如何检索保存的数据。 我们对系统进行了全面的审查，并发现在Java和Oracle的经典堆栈中，总会有一些ORM将关系数据转换为对象数据。 那么，为什么不仅仅以图形的形式将对象馈送到系统呢？ 这就是为什么我们很乐意选择满足我们需求的GraphQL的原因。 它使数据能够以图形形式获得，并且仅检索当前所需的数据。 甚至可以对API进行版本控制，具有足够的灵活性。
Almost at once, we realized that retrievable data was not enough for us. We made functions which could be linked to objects in a model — essentially, calculated fields. That is, we link to a field some function which calculates mean quotation price, for example. An external user who requests the data doesn't even know that the field is a calculated field.
几乎一次，我们意识到可检索的数据对我们来说还不够。 我们制作了可以链接到模型中的对象的函数-本质上是计算字段。 也就是说，例如，我们将一些函数链接到一个字段，该函数计算平均报价。 请求数据的外部用户甚至都不知道该字段是计算字段。
We implemented an authentication system.
我们实施了身份验证系统。
Then we noticed that several roles were crystallizing out in our solution. Role is a kind of an aggregator of functions. Roles normally have different equipment utilization profiles:
然后我们注意到在我们的解决方案中明确了几个角色。 角色是一种功能聚合器。 角色通常具有不同的设备利用率配置文件：

• T-Connect: processes inbound connections, limited in CPU usage, consumes less memory, and doesn't store the status.
  T-Connect：处理入站连接，CPU使用率受到限制，消耗的内存更少，并且不存储状态。
• IB-Core: converts data it receives via Tarantool protocol, which means that it manipulates with tables. It doesn't store status as well, and it can be scaled.
  IB-Core：转换通过Tarantool协议接收的数据，这意味着它将使用表进行操作。 它也不存储状态，并且可以缩放。
• Storage: only saves data and uses no logic. The most simple interfaces are implemented in this role. It can be scaled through vshard.
  存储：仅保存数据，不使用逻辑。 最简单的接口以该角色实现。 可以通过vshard进行缩放。

That is, using roles, we unlinked different parts of the cluster from each other, which can be scaled independently.
也就是说，使用角色，我们可以将集群的不同部分彼此取消链接，而这些链接可以独立扩展。
This way, we created an asynchronous write of transactional data flow and a repair queue with an admin interface. The write is asynchronous from the business perspective: once we have reliably written data in our system, no matter where exactly, we will be able to confirm that. If we don't confirm, then something went wrong, and the data needs to be resent. This is what writing asynchrony is about.
这样，我们使用管理界面创建了事务数据流的异步写入和修复队列。 从业务角度看，写入是异步的：一旦我们在系统中可靠地写入了数据，无论在哪里，我们都可以确认这一点。 如果我们不确定，则出问题了，需要重新发送数据。 这就是编写异步的目的。

测试中 (Testing)

At the very start, we decided to instill test-driven development. We write unit tests in Lua using tarantool/tap framework, and integration tests in Python using pytest framework. Doing that, we got both developers and analysts involved in integration test writing.
从一开始，我们就决定注入测试驱动的开发。 我们使用tarantool / tap框架在Lua中编写单元测试，并使用pytest框架在Python中编写集成测试。 这样做，我们让开发人员和分析人员都参与了集成测试编写。
How do we use test-driven development?
我们如何使用测试驱动的开发？
When we want a new feature, we try to write a test for it first. Once a bug is found, we always write a test before fixing it. It is hard to work this way at first, and there are a misunderstanding and even opposition on the part of the staff, like: «Let's fix it now, then do something new, and then cover it with tests.» However, this almost never happens.
当我们想要一个新功能时，我们首先尝试为其编写测试。 一旦发现错误，我们总是在修复之前编写测试。 起初很难以这种方式进行工作，并且员工之间存在误解甚至反对，例如：“现在就修复它，然后再做新的事情，然后进行测试。” 但是，这几乎永远不会发生。
So one needs to will oneself into writing tests in the first place, and make others do the same. Take my word for it, test-driven development pays even in the short term. It will make your life easier. In our perception, about 99% of all code is covered with tests. Quite a lot as it seems, but we have no problem with it: tests are run for every commit.
因此，首先需要一个人自己编写测试，并让其他人也做同样的事情。 相信我，即使在短期内，测试驱动的开发也能带来回报。 这将使您的生活更轻松。 据我们了解，所有代码中约有99％被测试覆盖。 看起来很多，但是我们没有问题：每次提交都会运行测试。
Yet, we like load testing most. We consider it the most important thing and run such tests on a regular.
但是，我们最喜欢负载测试。 我们认为这是最重要的事情，并定期进行此类测试。
I'm going to tell you a story about how we conducted the first stage of load testing for one of the initial versions. We installed the system on developer's laptop PC, engaged the load, and got 4 thousand transactions per second. Not bad for a laptop. Then we installed it on a virtual loading test bench comprised of four servers with performance lower than in production. Made a minimum deployment. After launch, we saw that the result was worse than on the laptop in one thread. It was a shock.
我将告诉您一个有关我们如何对其中一个初始版本进行负载测试的第一阶段的故事。 我们将系统安装在开发人员的便携式PC上，处理了负载，并每秒获得4000笔交易。 对于笔记本电脑来说还不错。 然后，我们将其安装在由四台服务器组成的虚拟负载测试台上，性能低于生产环境。 进行了最低限度的部署。 启动后，我们发现结果比一台笔记本电脑的结果差。 真是震惊。
Really discouraging. A check of loads on servers showed that they were idle.
真令人沮丧。 检查服务器上的负载表明它们处于空闲状态。
We called the developers, and they told us, people from Java world, that there is only one transaction processor thread in Tarantool. It can be effectively used by only one CPU core under load. With this in mind, we then deployed the maximum possible Tarantool instances on each server, engaged load, and got 14.5 thousand transactions per second.
我们打电话给开发人员，他们告诉我们Java世界的人们，Tarantool中只有一个事务处理器线程。 负载下只有一个CPU内核可以有效地使用它。 考虑到这一点，我们随后在每台服务器上部署了最大可能的Tarantool实例，进行了负载处理，并每秒获得1.45万笔交易。
Let me explain one more time. Due to the split-up into roles that use resources differently, our roles responsible for connections processing and data conversion loaded only the CPU, and strictly in proportion to the load.
让我再解释一次。 由于划分为使用不同资源的角色，我们负责连接处理和数据转换的角色仅加载CPU，并且严格按负载比例加载。
Meanwhile, memory was used only for processing inbound connections and transient objects.
同时，内存仅用于处理入站连接和临时对象。
The situation was opposite for storage servers: CPU load was growing, but much slower than for the servers doing connection processing.
对于存储服务器，情况恰恰相反：CPU负载正在增长，但比进行连接处理的服务器要慢得多。
Memory usage was growing in direct proportion to the amount of data being loaded.
内存使用量与加载的数据量成正比。

服务 (Services)

To develop our new product exactly as an application platform, we made a component for deploying services and libraries on it.
为了完全按照应用平台开发我们的新产品，我们制作了一个组件，用于在其上部署服务和库。
Services are not just small pieces of code that handle some fields. They can be rather big and complex structures that form a part of a cluster, check reference data, turn over the business logic, and provide responses. The scheme of the service is also exported to GraphQL, and the user gets a one-stop point of access to data, with introspection across the whole model. Quite handy.
服务不仅仅是处理某些字段的一小段代码。 它们可能是相当大而复杂的结构，它们构成集群的一部分，检查参考数据，上交业务逻辑并提供响应。 该服务的方案也已导出到GraphQL，并且用户可以一站式访问数据，并且可以对整个模型进行自省。 非常方便。
Since services include many more functions, we decided that there should be some libraries where we would keep frequently used code. We added those to a safe environment, having verified that nothing is broken as a result. Now we could assign to functions additional environments in the form of libraries.
由于服务包含更多功能，因此我们决定应该有一些库来保存常用代码。 我们已将它们添加到安全的环境中，并验证了结果没有损坏。 现在我们可以以库的形式为函数分配其他环境。
We wanted to have a platform for both storing data and computing. Since we had a whole lot of replicas and shards, we implemented a semblance of distributed computing and named it «map-reduce», because it was looking like the original map-reduce.
我们希望有一个同时存储数据和计算的平台。 由于我们有大量的副本和分片，因此我们实现了分布式计算的外观并将其命名为“ map-reduce”，因为它看起来像原始的map-reduce。

旧版系统 (Legacy systems)

Not all of our legacy systems can call us via HTTP and use GraphQL, although they support it. That is why we made a tool enabling data replication to those systems.
尽管我们的所有旧系统都支持，但并非所有旧系统都可以通过HTTP调用我们并使用GraphQL。 这就是为什么我们制作了一个工具，可以将数据复制到这些系统。
If something changes in our systems, some triggers operate in the Storage role, and a message with the changes gets to the processing queue. The message is sent to an external system via a separate replicator role. This role doesn't store status.
如果我们的系统发生了某些变化，则某些触发器将以“存储”角色运行，并且包含更改的消息将进入处理队列。 消息通过单独的复制器角色发送到外部系统。 该角色不存储状态。

新修改 (New modifications)

As you remember, we made an asynchronous write from a business perspective. But then we realized that it won't be enough, because there is a class of systems which need to receive a response with operation status right away. So we extended our GraphQL and added mutations. They fit into the existing data handling paradigm quite naturally. In our systems, it is a single reading and writing point for another class of systems.
您还记得，我们从业务角度进行了异步写入。 但是后来我们意识到这还不够，因为有一类系统需要立即接收操作状态的响应。 因此，我们扩展了GraphQL并添加了突变。 它们很自然地适合现有的数据处理范例。 在我们的系统中，它是另一类系统的单一读写点。
We also realized that services alone won't be enough for us, because there can be rather heavy reports which need to be built daily, weekly, and monthly. It may take longer, and the reports can even block Tarantool's event loop. That is why we set up separate roles: scheduler and runner. Runners don't store status. They run heavy tasks that we cannot read on the fly. As to the scheduler role, it supervises the launch schedule for those tasks, which is specified in the configuration. The tasks themselves are stored in the same place as business data. When the time is right, the scheduler takes a task, gives it to a runner, the runner calculates it, and saves the result.
我们还意识到仅靠服务不足以提供足够的服务，因为每天，每周和每月都需要建立大量报告。 这可能需要更长的时间，并且报告甚至可能阻止Tarantool的事件循环。 这就是为什么我们设置单独的角色的原因：调度程序和运行程序。 跑步者不存储状态。 他们执行繁重的任务，我们无法即时阅读。 至于调度程序角色，它监督这些任务的启动时间表，该任务在配置中指定。 任务本身与业务数据存储在同一位置。 当时间合适时，调度程序会执行一项任务，将其交给跑步者，跑步者对其进行计算并保存结果。
Not all tasks are to be run according to schedule. Some need to be calculated on demand. As soon as such a query comes, a task is generated in the sandbox and sent to a runner for execution. After some time, the user asynchronously receives a response telling that calculation is complete and the report is ready.
并非所有任务都将按计划运行。 有些需要按需计算。 一旦出现此类查询，就会在沙箱中生成一个任务，并将其发送给运行程序以执行。 一段时间后，用户异步收到响应，告知计算已完成且报告已准备就绪。
Initially, we adhered to the paradigm of saving all data by versioning and not deleting it. But in real life, we still need to delete something from time to time, such as, basically, some raw data or temporary information. On the basis of expirations, we made a tool for cleaning the storage from obsolete data.
最初，我们坚持通过版本控制保存所有数据而不删除它的范例。 但是在现实生活中，我们仍然需要不时删除某些内容，例如基本上是一些原始数据或临时信息。 根据有效期，我们开发了一种工具，用于清除过时的数据。
We also realize that, sooner or later, there will be a situation where there is not enough storage space, but the data still needs to be stored. For this purpose, we're going to make disk storage soon.
我们还意识到，迟早会有一种情况，即存储空间不足，但是仍然需要存储数据。 为此，我们将很快进行磁盘存储。

结论 (Conclusion)

We started with the objective of loading data to a single model and spent three months developing it. We had six data supplier systems. The whole code for transformation to a single model is around 30 strings in Lua. The greater part of the work is yet to be done. Sometimes, there's a lack of motivation in adjacent teams, and there are many circumstances making the work more difficult. If you ever face a similar objective, then the time you think will be enough to achieve it should be multiplied by three, or even four.
我们的目标是将数据加载到单个模型中，并花了三个月的时间来开发它。 我们有六个数据提供者系统。 在Lua中，用于转换为单个模型的整个代码约为30个字符串。 大部分工作尚未完成。 有时，相邻团队缺乏动力，并且在许多情况下使工作更加困难。 如果您面临类似的目标，那么您认为足以实现目标的时间应乘以三，甚至四倍。
Also, remember that existing issues with business processes cannot be resolved using a new data management system, even a high-performance one. What do I mean by this? At the start of our project, we made the customer believe that everything would run like a clockwork once we bring in a new fast database. Processes would run faster, and everything would be OK. In fact, technology cannot resolve all issues that occur in business processes, because business processes are about people. It is people that you should deal with, not technology.
另外，请记住，使用新的数据管理系统甚至是高性能的系统都无法解决业务流程中的现有问题。 我是什么意思 在项目开始时，我们让客户相信，一旦引入新的快速数据库，一切都会像发条一样运转。 进程将运行得更快，一切都会好起来的。 实际上，技术无法解决业务流程中发生的所有问题，因为业务流程与人有关。 您应该与人打交道，而不是技术。
Development through testing at an early stage may be a headache, and it may take very long. But the benefit will be sensible even in the short term when you have to do nothing to conduct regression testing.
早期通过测试进行开发可能会令人头疼，并且可能需要很长时间。 但是，即使在短期内您无需执行任何回归测试时，收益也将是明智的。
It is essential to run load tests at all development stages. The earlier you find a fault in architecture, the easier it will be to correct it, saving you a lot of time in the future.
在所有开发阶段都必须进行负载测试。 您越早发现架构故障，就越容易纠正它，从而在将来节省了很多时间。
There is nothing bad in Lua. Everyone can learn to write in it: a Java developer, a JavaScript developer, a Python developer, a front-ender, or a back-ender. We have even analysts writing in it.
Lua中没有什么不好的。 每个人都可以学习编写代码：Java开发人员，JavaScript开发人员，Python开发人员，前端或后端。 我们甚至有分析师在其中撰写。
When we tell people that we don't have SQL, it makes them scared. «How do you retrieve data without SQL? Is it possible?» Sure. There's no need for SQL in an OLTP class system. There is an alternative in the form of a language that returns to you a document-oriented view. GraphQL, for example. Another alternative is distributed computing.
当我们告诉人们我们没有SQL时，这会使他们感到害怕。 «如何在不使用SQL的情况下检索数据？ 可能吗？” 当然。 OLTP类系统中不需要SQL。 有一种语言形式的替代方法可以返回给您一个面向文档的视图。 例如，GraphQL。 另一种选择是分布式计算。
If you realize that you will have to scale up or down, then you should, at the very beginning, design your Tarantool-based solution so that it's able to operate in parallel with tens of Tarantool instances. If you don't, you are going to face difficulties and pain at a later stage, because Tarantool can use only one CPU core effectively.
如果您意识到必须向上或向下扩展，则应从一开始就设计基于Tarantool的解决方案，以使其能够与数十个Tarantool实例并行运行。 否则，您将在以后遇到困难和痛苦，因为Tarantool只能有效使用一个CPU内核。

翻译自: https://habr.com/en/company/mailru/blog/508340/

alfa 卡王