Cảnh trong phim “Vũ trụ bí mật của chúng ta: Cuộc sống ẩn giấu của tế bào”

Kinh doanh đầu tư là một trong những lĩnh vực phức tạp nhất trong thế giới ngân hàng, bởi vì không chỉ có các khoản vay, tiền vay và tiền gửi mà còn có chứng khoán, tiền tệ, hàng hóa, công cụ phái sinh và tất cả các loại phức tạp dưới dạng sản phẩm có cấu trúc.

Gần đây, chúng ta đã thấy sự hiểu biết về tài chính của người dân ngày càng tăng. Ngày càng có nhiều người tham gia giao dịch trên thị trường chứng khoán. Tài khoản đầu tư cá nhân xuất hiện cách đây không lâu. Chúng cho phép bạn giao dịch trên thị trường chứng khoán và được khấu trừ thuế hoặc tránh phải nộp thuế. Và tất cả khách hàng đến với chúng tôi đều muốn quản lý danh mục đầu tư của mình và xem báo cáo theo thời gian thực. Hơn nữa, hầu hết danh mục đầu tư này thường là nhiều sản phẩm, nghĩa là mọi người là khách hàng của nhiều ngành nghề kinh doanh khác nhau.

Ngoài ra, nhu cầu của các cơ quan quản lý, cả Nga và nước ngoài, đều ngày càng tăng.

Để đáp ứng nhu cầu hiện tại và đặt nền tảng cho những nâng cấp trong tương lai, chúng tôi đã phát triển cốt lõi kinh doanh đầu tư dựa trên Tarantool.

Một số thống kê. Hoạt động kinh doanh đầu tư của Alfa-Bank cung cấp dịch vụ môi giới cho các cá nhân và pháp nhân nhằm tạo cơ hội giao dịch trên nhiều thị trường chứng khoán khác nhau, dịch vụ lưu ký để lưu trữ chứng khoán, dịch vụ quản lý ủy thác cho cá nhân có vốn tư nhân và lớn, dịch vụ phát hành chứng khoán cho các công ty khác . Hoạt động kinh doanh đầu tư của Alfa-Bank bao gồm hơn 3 nghìn báo giá mỗi giây, được tải xuống từ nhiều nền tảng giao dịch khác nhau. Trong ngày làm việc, hơn 300 nghìn giao dịch được thực hiện trên thị trường thay mặt cho ngân hàng hoặc khách hàng của ngân hàng. Lên đến 5 nghìn lần thực hiện lệnh mỗi giây xảy ra trên nền tảng bên ngoài và bên trong. Đồng thời, tất cả khách hàng, cả bên trong và bên ngoài, đều muốn xem vị thế của mình theo thời gian thực.

thời tiền sử

Đâu đó từ đầu những năm 2000, các lĩnh vực kinh doanh đầu tư của chúng tôi đã phát triển độc lập: giao dịch trao đổi, dịch vụ môi giới, giao dịch tiền tệ, giao dịch chứng khoán và các công cụ phái sinh khác nhau. Kết quả là chúng ta đã rơi vào bẫy của những chiếc giếng chức năng. Nó là gì? Mỗi ngành nghề kinh doanh có hệ thống riêng sao chép chức năng của nhau. Mỗi hệ thống có mô hình dữ liệu riêng, mặc dù chúng hoạt động với các khái niệm giống nhau: giao dịch, công cụ, đối tác, báo giá, v.v. Và khi mỗi hệ thống phát triển độc lập, một loạt công nghệ đa dạng đã xuất hiện.

Ngoài ra, cơ sở mã của các hệ thống đã khá lỗi thời vì một số sản phẩm có nguồn gốc từ giữa những năm 1990. Và ở một số khu vực, điều này đã làm chậm quá trình phát triển và gây ra các vấn đề về hiệu suất.

Yêu cầu đối với giải pháp mới

Các doanh nghiệp đã nhận ra rằng chuyển đổi công nghệ là rất quan trọng để phát triển hơn nữa. Chúng tôi được giao nhiệm vụ:

1. Thu thập tất cả dữ liệu kinh doanh trong một bộ lưu trữ nhanh, duy nhất và trong một mô hình dữ liệu duy nhất.
2. Chúng ta không được mất hoặc thay đổi thông tin này.
3. Việc phiên bản dữ liệu là cần thiết vì bất cứ lúc nào cơ quan quản lý cũng có thể yêu cầu số liệu thống kê của những năm trước.
4. Chúng ta không chỉ phải mang đến một số DBMS mới, hợp thời mà còn phải tạo ra một nền tảng để giải quyết các vấn đề kinh doanh.

Ngoài ra, các kiến ​​trúc sư của chúng tôi đặt ra các điều kiện riêng:

1. Giải pháp mới phải ở cấp độ doanh nghiệp, nghĩa là nó phải được thử nghiệm ở một số công ty lớn.
2. Chế độ vận hành của giải pháp phải là nhiệm vụ quan trọng. Điều này có nghĩa là chúng tôi phải có mặt đồng thời ở một số trung tâm dữ liệu và bình tĩnh sống sót sau khi một trung tâm dữ liệu ngừng hoạt động.
3. Hệ thống phải có khả năng mở rộng theo chiều ngang. Thực tế là tất cả các hệ thống hiện tại của chúng tôi chỉ có khả năng mở rộng theo chiều dọc và chúng tôi đã đạt đến mức trần do sức mạnh phần cứng tăng trưởng thấp. Vì vậy, đã đến lúc chúng ta cần có một hệ thống có thể mở rộng theo chiều ngang để tồn tại.
4. Trong số những điều khác, chúng tôi được thông báo rằng giải pháp phải rẻ.

Chúng tôi đã đi theo lộ trình tiêu chuẩn: chúng tôi đưa ra các yêu cầu và liên hệ với bộ phận mua hàng. Từ đó, chúng tôi nhận được danh sách các công ty nói chung sẵn sàng làm việc này cho chúng tôi. Chúng tôi đã nói với mọi người về vấn đề này và nhận được đánh giá về giải pháp từ sáu người trong số họ.

Tại ngân hàng, chúng tôi không tin lời ai cả; chúng tôi muốn tự mình kiểm tra mọi thứ. Vì vậy, điều kiện bắt buộc trong cuộc cạnh tranh đấu thầu của chúng tôi là phải vượt qua các bài kiểm tra tải trọng. Chúng tôi đã xây dựng các nhiệm vụ kiểm tra tải và ba trong số sáu công ty đã đồng ý triển khai giải pháp nguyên mẫu dựa trên công nghệ trong bộ nhớ bằng chi phí riêng của họ để kiểm tra giải pháp đó.

Tôi sẽ không cho bạn biết chúng tôi đã thử nghiệm mọi thứ như thế nào và mất bao lâu, tôi sẽ chỉ tóm tắt: hiệu suất tốt nhất trong các thử nghiệm tải được thể hiện bằng giải pháp nguyên mẫu dựa trên Tarantool từ nhóm phát triển Mail.ru Group. Chúng tôi đã ký một thỏa thuận và bắt đầu phát triển. Có bốn người từ Tập đoàn Mail.ru và từ Alfa-Bank có ba nhà phát triển, ba nhà phân tích hệ thống, một kiến ​​trúc sư giải pháp, một chủ sở hữu sản phẩm và một bậc thầy Scrum.

Tiếp theo, tôi sẽ cho bạn biết hệ thống của chúng tôi đã phát triển như thế nào, nó phát triển như thế nào, chúng tôi đã làm gì và chính xác là tại sao lại như vậy.

Phát triển

Câu hỏi đầu tiên chúng tôi tự hỏi là làm cách nào để lấy dữ liệu từ hệ thống hiện tại của chúng tôi. Chúng tôi quyết định rằng HTTP khá phù hợp với chúng tôi, vì tất cả các hệ thống hiện tại đều giao tiếp với nhau bằng cách gửi XML hoặc JSON qua HTTP.

Chúng tôi sử dụng máy chủ HTTP được tích hợp trong Tarantool vì chúng tôi không cần chấm dứt các phiên SSL và hiệu suất của nó là đủ đối với chúng tôi.

Như tôi đã nói, tất cả các hệ thống của chúng tôi đều tồn tại trong các mô hình dữ liệu khác nhau và ở đầu vào, chúng tôi cần đưa đối tượng đến mô hình mà chúng tôi tự mô tả. Cần có một ngôn ngữ cho phép chuyển đổi dữ liệu. Chúng tôi đã chọn Lua mệnh lệnh. Chúng tôi chạy tất cả mã chuyển đổi dữ liệu trong hộp cát - đây là nơi an toàn mà mã đang chạy không đi tới. Để làm điều này, chúng tôi chỉ cần tải chuỗi mã được yêu cầu, tạo một môi trường có các chức năng không thể chặn hoặc loại bỏ bất cứ thứ gì.

Sau khi chuyển đổi, dữ liệu phải được kiểm tra xem có tuân thủ mô hình mà chúng ta đang tạo hay không. Chúng tôi đã thảo luận rất lâu về mô hình nên là gì và sử dụng ngôn ngữ nào để mô tả nó. Chúng tôi chọn Apache Avro vì ngôn ngữ đơn giản và có sự hỗ trợ từ Tarantool. Các phiên bản mới của mô hình và mã tùy chỉnh có thể được đưa vào hoạt động nhiều lần trong ngày, ngay cả khi có tải hoặc không có tải, vào bất kỳ thời điểm nào trong ngày và thích ứng với những thay đổi rất nhanh.

Sau khi xác minh, dữ liệu phải được lưu lại. Chúng tôi thực hiện việc này bằng cách sử dụng vshard (chúng tôi có các bản sao phân tán theo địa lý).

Hơn nữa, tính đặc hiệu đến mức hầu hết các hệ thống gửi dữ liệu cho chúng tôi đều không quan tâm liệu chúng tôi có nhận được dữ liệu đó hay không. Đó là lý do tại sao chúng tôi triển khai hàng đợi sửa chữa ngay từ đầu. Nó là gì? Nếu vì lý do nào đó mà đối tượng không trải qua quá trình chuyển đổi hoặc xác minh dữ liệu, chúng tôi vẫn xác nhận đã nhận, nhưng đồng thời lưu đối tượng vào hàng đợi sửa chữa. Nó nhất quán và nằm trong kho dữ liệu kinh doanh chính. Chúng tôi ngay lập tức viết giao diện quản trị viên cho nó, với nhiều số liệu và cảnh báo khác nhau. Kết quả là chúng tôi không bị mất dữ liệu. Ngay cả khi có điều gì đó thay đổi trong nguồn, nếu mô hình dữ liệu thay đổi, chúng tôi sẽ phát hiện ngay và có thể điều chỉnh.

Bây giờ bạn cần học cách lấy lại dữ liệu đã lưu. Chúng tôi đã phân tích cẩn thận các hệ thống của mình và thấy rằng ngăn xếp cổ điển của Java và Oracle nhất thiết phải chứa một số loại ORM giúp chuyển đổi dữ liệu từ quan hệ sang đối tượng. Vậy tại sao không đưa ngay đối tượng cho hệ thống dưới dạng biểu đồ? Vì vậy, chúng tôi vui vẻ áp dụng GraphQL, đáp ứng mọi nhu cầu của chúng tôi. Nó cho phép bạn nhận dữ liệu dưới dạng biểu đồ và chỉ lấy ra những gì bạn cần ngay bây giờ. Bạn thậm chí có thể tạo phiên bản API khá linh hoạt.

Gần như ngay lập tức chúng tôi nhận ra rằng dữ liệu chúng tôi trích xuất là không đủ. Chúng tôi đã tạo các hàm có thể được liên kết với các đối tượng trong mô hình - về cơ bản là các trường được tính toán. Nghĩa là, chúng tôi gắn một hàm nhất định vào trường, chẳng hạn như tính giá báo giá trung bình. Và người tiêu dùng bên ngoài yêu cầu dữ liệu thậm chí không biết rằng đây là trường được tính toán.

Triển khai hệ thống xác thực.

Sau đó, chúng tôi nhận thấy rằng một số vai trò đã được thể hiện trong quyết định của chúng tôi. Vai trò là một loại tập hợp các chức năng. Thông thường, các vai trò có hồ sơ sử dụng thiết bị khác nhau:

• T-Connect: xử lý các kết nối đến, giới hạn CPU, tiêu thụ bộ nhớ thấp, không trạng thái.
• IB-Core: biến đổi dữ liệu mà nó nhận được thông qua giao thức Tarantool, nghĩa là nó hoạt động với các bảng. Nó cũng không lưu trữ trạng thái và có thể mở rộng.
• Lưu trữ: chỉ lưu trữ dữ liệu, không sử dụng bất kỳ logic nào. Vai trò này thực hiện các giao diện đơn giản nhất. Có thể mở rộng nhờ vshard.

Nghĩa là, bằng cách sử dụng các vai trò, chúng tôi đã tách các phần khác nhau của cụm ra khỏi nhau, các phần này có thể được mở rộng quy mô độc lập với nhau.

Vì vậy, chúng tôi đã tạo bản ghi luồng dữ liệu giao dịch không đồng bộ và hàng sửa chữa với giao diện quản trị viên. Bản ghi không đồng bộ theo quan điểm kinh doanh: nếu chúng tôi được đảm bảo ghi dữ liệu cho chính mình, bất kể ở đâu, thì chúng tôi sẽ xác nhận nó. Nếu nó không được xác nhận thì có nghĩa là đã xảy ra lỗi và dữ liệu cần được gửi đi. Đây là bản ghi không đồng bộ.

Kiểm tra

Ngay từ khi bắt đầu dự án, chúng tôi đã quyết định sẽ cố gắng triển khai quá trình phát triển theo hướng thử nghiệm. Chúng tôi viết các bài kiểm thử đơn vị trong Lua bằng khung tarantool/tap và các bài kiểm thử tích hợp trong Python bằng khung pytest. Đồng thời, chúng tôi thu hút cả nhà phát triển và nhà phân tích viết bài kiểm tra tích hợp.

Chúng tôi sử dụng tính năng phát triển theo hướng thử nghiệm như thế nào?

Nếu chúng tôi muốn một số tính năng mới, chúng tôi sẽ cố gắng viết thử nghiệm cho nó trước. Khi chúng tôi phát hiện ra một lỗi, chúng tôi đảm bảo viết bài kiểm tra trước và sau đó mới sửa lỗi đó. Lúc đầu, làm việc như thế này thật khó khăn, có sự hiểu lầm từ phía nhân viên, thậm chí là phá hoại: “Chúng ta hãy nhanh chóng khắc phục ngay bây giờ, làm điều gì đó mới và sau đó kiểm tra nó lại”. Chỉ có điều “sau này” này hầu như không bao giờ đến.

Vì vậy, bạn cần ép mình viết bài test trước và nhờ người khác làm. Hãy tin tôi, sự phát triển dựa trên thử nghiệm mang lại lợi ích ngay cả trong thời gian ngắn. Bạn sẽ cảm thấy cuộc sống của mình trở nên dễ dàng hơn. Chúng tôi cảm thấy rằng 99% mã hiện đã được kiểm tra. Con số này có vẻ nhiều, nhưng chúng tôi không gặp bất kỳ vấn đề gì: các bài kiểm tra chạy trên mọi lần xác nhận.

Tuy nhiên, điều chúng tôi yêu thích nhất là kiểm tra tải, chúng tôi coi đó là điều quan trọng nhất và thực hiện thường xuyên.

Tôi sẽ kể cho bạn một câu chuyện nhỏ về cách chúng tôi thực hiện giai đoạn thử nghiệm tải đầu tiên của một trong những phiên bản đầu tiên. Chúng tôi đã cài đặt hệ thống trên máy tính xách tay của nhà phát triển, bật tải và nhận được 4 nghìn giao dịch mỗi giây. Kết quả tốt cho một máy tính xách tay. Chúng tôi đã cài đặt nó trên một băng ghế tải ảo gồm bốn máy chủ, yếu hơn so với phiên bản sản xuất. Triển khai ở mức tối thiểu. Chúng tôi chạy nó và nhận được kết quả tệ hơn trên máy tính xách tay trong một luồng. Nội dung gây sốc.

Chúng tôi rất buồn. Chúng tôi xem xét tải của máy chủ, nhưng hóa ra chúng không hoạt động.

Chúng tôi gọi cho các nhà phát triển và họ giải thích cho chúng tôi, những người đến từ thế giới Java, rằng Tarantool là một luồng đơn. Nó chỉ có thể được sử dụng hiệu quả bởi một lõi xử lý đang tải. Sau đó, chúng tôi đã triển khai số lượng phiên bản Tarantool tối đa có thể trên mỗi máy chủ, bật tải và đã nhận được 14,5 nghìn giao dịch mỗi giây.

Hãy để tôi giải thích lại. Do sự phân chia thành các vai trò sử dụng tài nguyên khác nhau nên vai trò của chúng tôi chịu trách nhiệm xử lý kết nối và chuyển đổi dữ liệu chỉ tải bộ xử lý và tỷ lệ thuận với tải.

Trong trường hợp này, bộ nhớ chỉ được sử dụng để xử lý các kết nối đến và các đối tượng tạm thời.

Ngược lại, trên các máy chủ lưu trữ, tải bộ xử lý tăng lên nhưng chậm hơn nhiều so với trên các máy chủ xử lý kết nối.

Và mức tiêu thụ bộ nhớ tăng tỷ lệ thuận với lượng dữ liệu được tải.

Dịch vụ

Để phát triển sản phẩm mới của chúng tôi một cách cụ thể như một nền tảng ứng dụng, chúng tôi đã tạo một thành phần để triển khai các dịch vụ và thư viện trên đó.

Dịch vụ không chỉ là những đoạn mã nhỏ hoạt động trên một số trường. Chúng có thể là các cấu trúc khá lớn và phức tạp, là một phần của cụm, kiểm tra dữ liệu tham chiếu, chạy logic nghiệp vụ và trả về các phản hồi. Chúng tôi cũng xuất lược đồ dịch vụ sang GraphQL và người tiêu dùng nhận được một điểm truy cập chung vào dữ liệu, với khả năng xem xét nội tâm trên toàn bộ mô hình. Nó rất thoải mái.

Vì các dịch vụ chứa nhiều chức năng hơn nên chúng tôi quyết định rằng cần có các thư viện để chúng tôi di chuyển mã được sử dụng thường xuyên. Chúng tôi đã thêm chúng vào môi trường an toàn, trước đó đã kiểm tra rằng nó không ảnh hưởng gì đến chúng tôi. Và bây giờ chúng ta có thể gán môi trường bổ sung cho các hàm dưới dạng thư viện.

Chúng tôi muốn có một nền tảng không chỉ để lưu trữ mà còn cho máy tính. Và vì chúng tôi đã có rất nhiều bản sao và phân đoạn, nên chúng tôi đã triển khai một loại tính toán phân tán và gọi nó là thu nhỏ bản đồ, vì hóa ra nó tương tự như bản đồ thu nhỏ ban đầu.

Hệ thống cũ

Không phải tất cả các hệ thống cũ của chúng tôi đều có thể gọi cho chúng tôi qua HTTP và sử dụng GraphQL, mặc dù chúng hỗ trợ giao thức. Do đó, chúng tôi đã tạo ra một cơ chế cho phép sao chép dữ liệu vào các hệ thống này.

Nếu có điều gì đó thay đổi đối với chúng tôi, các trình kích hoạt duy nhất sẽ được kích hoạt trong vai trò Lưu trữ và thông báo về các thay đổi sẽ được đưa vào hàng xử lý. Nó được gửi đến một hệ thống bên ngoài bằng cách sử dụng vai trò sao chép riêng biệt. Vai trò này không lưu trữ trạng thái.

Những cải tiến mới

Như bạn nhớ, từ quan điểm kinh doanh, chúng tôi đã ghi âm không đồng bộ. Nhưng sau đó họ nhận ra rằng điều đó là chưa đủ, bởi vì có một loại hệ thống cần nhận được phản hồi ngay lập tức về trạng thái hoạt động. Vì vậy, chúng tôi đã mở rộng GraphQL và thêm các đột biến. Chúng hoàn toàn phù hợp với mô hình làm việc với dữ liệu hiện có. Đối với chúng tôi, đây là một điểm duy nhất của cả việc đọc và viết đối với một lớp hệ thống khác.

Chúng tôi cũng nhận ra rằng chỉ dịch vụ thôi thì chưa đủ đối với chúng tôi, vì có những báo cáo khá nặng cần phải xây dựng mỗi ngày, một tuần, một tháng một lần. Việc này có thể mất nhiều thời gian và các báo cáo thậm chí có thể chặn vòng lặp sự kiện của Tarantool. Do đó, chúng tôi đã tạo các vai trò riêng biệt: người lên lịch và người chạy. Người chạy không lưu trữ trạng thái. Họ chạy những nhiệm vụ nặng nề mà chúng tôi không thể tính toán ngay lập tức. Và vai trò người lập lịch trình giám sát lịch khởi chạy của các tác vụ này, được mô tả trong cấu hình. Bản thân các nhiệm vụ được lưu trữ ở cùng nơi với dữ liệu kinh doanh. Khi đến thời điểm thích hợp, người lập lịch nhận nhiệm vụ, giao nó cho một người chạy nào đó, người này đếm và lưu kết quả.

Không phải tất cả các nhiệm vụ cần phải được thực hiện theo lịch trình. Một số báo cáo cần được đọc theo yêu cầu. Ngay khi có yêu cầu này, một tác vụ sẽ được tạo trong hộp cát và gửi đến người chạy để thực thi. Sau một thời gian, người dùng nhận được phản hồi không đồng bộ rằng mọi thứ đã được tính toán và báo cáo đã sẵn sàng.

Ban đầu, chúng tôi tuân thủ mô hình lưu trữ tất cả dữ liệu, lập phiên bản và không xóa dữ liệu. Nhưng trong cuộc sống, thỉnh thoảng bạn vẫn phải xóa đi một điều gì đó, chủ yếu là một số thông tin thô hoặc trung gian. Dựa trên dữ liệu đã hết hạn, chúng tôi đã tạo cơ chế dọn dẹp bộ lưu trữ khỏi dữ liệu lỗi thời.

Chúng tôi cũng hiểu rằng sớm hay muộn sẽ xảy ra tình huống không còn đủ dung lượng để lưu trữ dữ liệu trong bộ nhớ nhưng dữ liệu vẫn phải được lưu trữ. Vì những mục đích này, chúng tôi sẽ sớm tạo bộ lưu trữ trên đĩa.

Kết luận

Chúng tôi bắt đầu với nhiệm vụ tải dữ liệu vào một mô hình duy nhất và dành ba tháng để phát triển nó. Chúng tôi có sáu hệ thống cung cấp dữ liệu. Toàn bộ mã chuyển đổi thành một mô hình duy nhất dài khoảng 30 nghìn dòng trong Lua. Và hầu hết công việc vẫn còn ở phía trước. Đôi khi thiếu động lực từ các đội lân cận và có nhiều tình huống khiến công việc trở nên phức tạp. Nếu bạn từng phải đối mặt với một nhiệm vụ tương tự, hãy nhân thời gian mà bạn thấy bình thường để thực hiện nó với ba hoặc thậm chí bốn.

Cũng nên nhớ rằng các vấn đề hiện tại trong quy trình kinh doanh không thể được giải quyết bằng cách sử dụng DBMS mới, ngay cả khi sử dụng một hệ quản trị cơ sở dữ liệu rất hiệu quả. Ý tôi là gì? Khi bắt đầu dự án, chúng tôi đã tạo ấn tượng với khách hàng rằng bây giờ chúng tôi sẽ mang đến một cơ sở dữ liệu nhanh mới và chúng tôi sẽ tồn tại! Các quá trình sẽ diễn ra nhanh hơn, mọi thứ sẽ ổn. Trên thực tế, công nghệ không giải quyết được các vấn đề mà quy trình kinh doanh gặp phải, bởi vì quy trình kinh doanh chính là con người. Và bạn cần làm việc với con người chứ không phải công nghệ.

Phát triển dựa trên thử nghiệm có thể gây khó khăn và tốn thời gian trong giai đoạn đầu. Nhưng tác động tích cực của nó sẽ thấy rõ ngay cả trong thời gian ngắn, khi bạn không cần phải làm gì để tiến hành kiểm tra hồi quy.

Điều cực kỳ quan trọng là tiến hành kiểm tra tải ở tất cả các giai đoạn phát triển. Bạn nhận thấy một số lỗ hổng trong kiến ​​trúc càng sớm thì càng dễ sửa nó, điều này sẽ giúp bạn tiết kiệm rất nhiều thời gian trong tương lai.

Lua chẳng có gì sai cả. Bất cứ ai cũng có thể học viết trong đó: nhà phát triển Java, nhà phát triển JavaScript, nhà phát triển Python, front-end hoặc back-end. Ngay cả các nhà phân tích của chúng tôi cũng viết về nó.

Khi chúng tôi nói về việc chúng tôi không có SQL, điều đó khiến mọi người khiếp sợ. “Làm cách nào để lấy dữ liệu mà không cần SQL? Điều đó có thể không? Chắc chắn. Trong hệ thống lớp OLTP, SQL không cần thiết. Có một giải pháp thay thế dưới dạng một số loại ngôn ngữ sẽ ngay lập tức đưa bạn trở lại chế độ xem hướng tài liệu. Ví dụ: GraphQL. Và có một giải pháp thay thế dưới dạng điện toán phân tán.

Nếu bạn hiểu rằng mình sẽ cần mở rộng quy mô thì hãy thiết kế giải pháp của bạn trên Tarantool sao cho giải pháp đó có thể chạy song song trên hàng chục phiên bản Tarantool. Nếu không làm điều này thì sau này sẽ gặp khó khăn và đau đớn vì Tarantool chỉ có thể sử dụng hiệu quả một lõi xử lý.

Nguồn: www.habr.com