Triển khai VoltDB thành công

Question

Tôi đã làm việc trên một dự án trong hơn nửa năm nay, xây dựng phần mềm chăm sóc sức khỏe từ đầu. Khi tôi gia nhập, MySQL đã được chọn làm kho dữ liệu chính.

Một vài tháng và nhiều lần đau đầu sau đó, chúng tôi bắt đầu điều tra các cửa hàng dữ liệu thay thế có thể cung cấp sự linh hoạt mà chúng tôi cần ghi lại dữ liệu chăm sóc sức khỏe quan trọng và luôn thay đổi của mình.

Chúng tôi đã xem xét nhiều giải pháp NoSQL; MongoDB thu hút sự chú ý nhất của chúng tôi. Việc có thể lưu trữ dữ liệu có cấu trúc, được nhúng sẽ là một lợi ích rất lớn. Tuy nhiên, chúng tôi đã rất sợ các báo cáo về sự cố về mất dữ liệu/độ tin cậy.

Tôi đã gặp một số cửa hàng dữ liệu "NewSQL" và tôi quan tâm đến VoltDB nói riêng.

Tôi tò mò muốn biết nếu có ai có kinh nghiệm với Volt hoặc đã nhìn thấy nó thực hiện trong một dự án.

Edit:

toàn vẹn dữ liệu và tính nhất quán là quan trọng nhất. Nó có thể rất có hại cho thông tin bệnh nhân bị mất, họ có thể nhận được sự điều trị không đúng cách, v.v.

Khối lượng dữ liệu sẽ thay đổi; chúng tôi có thể sẽ hỗ trợ các thực hành nhỏ trước. Một cái gì đó như 700 người dùng tổng số. Nhưng ngay cả khi chúng tôi mở rộng quy mô lên bệnh viện, chúng tôi không xem xét các phương tiện truyền thông xã hội như giao thông.

Về câu hỏi của bạn, có cấu trúc dữ liệu sẽ phát triển. Trên đầu trang của việc phải thay đổi cấu trúc hiện có để nắm bắt các đầu vào mới hoặc sửa đổi, chúng ta phải bảo toàn cấu trúc của dữ liệu hiện có như một loại snap-shot. Chúng tôi chỉ có thể thực hiện phong cách EAV này với MySQL.

Cảm ơn phản hồi của bạn.

Answer 1

Chúng tôi đã phát trực tiếp năm ngoái với một ứng dụng sử dụng VoltDB. Chúng tôi đang lưu trữ khoảng 1,5 tỷ bản ghi và xử lý 50-90 triệu giao dịch mỗi ngày với cụm máy chủ kfactor = 1 4 (bộ nhớ/máy chủ 256 GB). Với hiệu suất của VoltDB, chúng ta có thể dễ dàng giao 1 tỷ giao dịch mỗi ngày.

Cho đến nay, chúng tôi không gặp vấn đề gì liên quan đến phần mềm VoltDB. Kinh nghiệm của chúng tôi là nó thực sự tuân thủ ACID. Với việc bổ sung tính năng Ghi nhật ký Lệnh, tôi tin rằng bạn có thể định cấu hình các tham số ghi nhật ký để loại trừ việc mất bất kỳ giao dịch nào.

Các tính năng mạnh khác bao gồm khả năng mở rộng của nó (và tính đơn giản tương đối để thêm dung lượng).

Một cân nhắc quan trọng khi chọn VoltDB là hiểu sơ đồ phân vùng của VoltDB. Đạt được tỷ lệ giao dịch rất cao có thể với VoltDB phụ thuộc vào sự song song đạt được thông qua phân vùng dữ liệu. Việc phân vùng là minh bạch cho ứng dụng của bạn, nhưng dữ liệu ứng dụng của bạn phải cho chính nó để được phân vùng để có được hiệu suất tối đa. Nếu dữ liệu của bạn không tự cho mình phân vùng, tôi tin rằng tác động chính sẽ là giảm thông lượng (tức là tỷ giá giao dịch) - không phải là điểm dừng chương trình.

Cuối cùng - một lưu ý liên quan đến các thủ tục được lưu trữ. VoltDB cho phép bạn thay thế các thủ tục lưu sẵn mà không cần dừng cơ sở dữ liệu. Ngoài ra, mỗi yêu cầu của một thủ tục lưu trữ cấu thành một giao dịch duy nhất. Chúng tôi đã tận dụng các thủ tục được lưu trữ theo cách mà chúng tôi có thể sửa đổi/cập nhật logic ứng dụng của mình mà không cần dừng cơ sở dữ liệu.

Answer 2

Câu hỏi, khi nó đứng, rất chủ quan, nhưng nhiều thông tin hơn có thể giúp chúng tôi chỉ cho bạn đúng hướng.

Chính xác yêu cầu của bạn là gì? Hệ thống này có các nhu cầu giao dịch trong đó tính toàn vẹn và nhất quán của dữ liệu có tầm quan trọng tối đa, chẳng hạn như các giao dịch và ứng dụng tài chính không? Khối lượng dữ liệu là gì và có bao nhiêu người dùng đồng thời? Các yêu cầu về hiệu suất là gì?

Ngoài ra, bạn đã đề cập ever-changing healthcare data, điều này có nghĩa là cấu trúc dữ liệu liên tục thay đổi và phát triển? Nếu vậy, bạn có thể muốn tránh xa các cơ sở dữ liệu quan hệ do tính chất của các lược đồ cứng nhắc và thay vào đó, hãy xem xét các cửa hàng tài liệu như Mongo, nơi cấu trúc dữ liệu schemaless cung cấp sự linh hoạt hơn.

BTW,

Đừng lo sợ về những câu chuyện đáng tin cậy trên Mongo; bạn có thể tìm thấy những câu chuyện kinh dị cho thực tế bất kỳ sản phẩm nào, cả nguồn mở và thương mại; thường thì những đánh giá xấu này có ít liên quan đến sản phẩm và hơn thế nữa với việc thực hiện khách hàng kém.

VoltDB, cuối cùng tôi đã kiểm tra, yêu cầu tất cả các logic liên tục phải được mã hóa như các thủ tục được lưu trữ. Những thiếu sót rõ ràng với cách tiếp cận này là ít khả năng hiển thị mã và mô đun, và nhu cầu bảo trì cao hơn. Bên cạnh đó, Voltdb là rất nhanh vì hầu hết các chi phí được tìm thấy trong cơ sở dữ liệu quan hệ truyền thống, chẳng hạn như khóa, vv, được loại bỏ khỏi cơ sở dữ liệu lõi.

Answer 3

Câu hỏi đặt ra là một chút ít tuổi, nhưng tôi đưa ra một số thông tin phản hồi bởi vì chúng tôi đã sử dụng MongoDB kể từ một thời gian dài, và chúng tôi đang tìm kiếm để VoltDB nhưng vì những lý do hoàn toàn khác nhau:

• Về MongoDB : chúng tôi đang sử dụng mongoDB trong sản xuất từ ​​4 năm và chúng tôi không bao giờ mất bất kỳ byte dữ liệu nào. "Mongodb không đáng tin cậy" có vẻ là một huyền thoại, ít nhất là đối với tôi. Chúng tôi đang quản lý hàng triệu mục mới trong mongoDB mỗi ngày mà không gặp bất kỳ vấn đề nào

• Chúng tôi đang tìm đến VoltDB cho một trường hợp sử dụng khác: cung cấp phân tích thời gian thực trên khối lượng lớn. MongoDB không phải là xấu trong việc cung cấp phân tích, nhưng khi bạn vượt quá hàng triệu mục được phân tích, nó bắt đầu hơi chậm. VoltDB là tốt hơn nhiều ở đây, nhưng tôi sẽ không khuyên bạn sử dụng nó để lưu trữ dữ liệu, đặc biệt là dữ liệu có giá trị cao .... Chúng tôi sử dụng cơ sở dữ liệu khác để lưu trữ dữ liệu.