Gần đây, tôi đã có cơ hội phỏng vấn Oren Eini, Giám đốc điều hành và người sáng lập Hibernating Rhinos, công ty cung cấp RavenDB, một NoSQL hướng tài liệu mã nguồn mở được thiết kế đặc biệt cho nền tảng .NET / Windows.
Oren có hơn 20 năm kinh nghiệm trong thế giới phát triển tập trung mạnh mẽ vào hệ sinh thái Microsoft và .NET. Được công nhận là một trong những Chuyên gia có giá trị nhất của Microsoft từ năm 2007, Oren cũng là tác giả của “DSLs in Boo:Domain Specific Languages in .NET”. Ông thường xuyên phát biểu tại các hội nghị trong ngành như DevTeach, JAOO, QCon, Oredev, NDC, Yow! và Progressive.NET.
Bạn có thể đọc toàn bộ cuộc phỏng vấn dưới đây:
1. Trong thế giới số hóa này, dữ liệu đã trở thành một trong những tài sản quý giá nhất. và do đó, cách dữ liệu được lưu trữ, tổ chức và xử lý là rất quan trọng đối với thành công của doanh nghiệp. Khi các công ty bị tấn công bởi ngày càng nhiều dữ liệu, việc lưu trữ và phân tích dữ liệu ngày càng phức tạp hơn. Bạn có thể cho chúng tôi biết một số thách thức quản lý cơ sở dữ liệu phổ biến mà các doanh nghiệp phải đối mặt hiện nay không?
Tôi tin rằng vấn đề chính chỉ là kích thước tuyệt đối của dữ liệu. Tôi không nhất thiết phải nói về Dữ liệu lớn và sự phức tạp của việc quản lý một tập dữ liệu được đo bằng hàng trăm terabyte. Tôi đang nói về số lượng cơ sở dữ liệu và kho dữ liệu mà bạn có trong một tổ chức. Vì mọi thứ đều là kỹ thuật số, bạn có chức năng quan trọng trong kinh doanh nằm trong bảng tính Excel trên bộ nhớ dùng chung và dữ liệu lịch sử về các giao dịch mua của khách hàng trong một máy chủ mà không ai muốn đến gần vì sợ chấp nhận quyền sở hữu.
Chỉ cần tìm ra những gì mà cả tổ chức biết có thể là một nhiệm vụ phức tạp. Đáng buồn là dữ liệu bị trượt qua các vết nứt là điều rất phổ biến.
Những nỗ lực tạo ra một kho lưu trữ tập trung cho toàn bộ công ty cũng thất bại. Các bộ phận khác nhau của công ty có những ý tưởng rất khác nhau về những thứ dường như hiển nhiên. Ví dụ, bộ phận Thanh toán có quan niệm rất khác về Khách hàng là gì so với bộ phận Tiếp thị. Cố gắng làm cho dữ liệu phù hợp với một khuôn mẫu chung không làm mọi người trở thành kẻ bất lợi.
2. Làm thế nào để chúng ta vượt qua những thách thức này? Bạn có nghĩ rằng lựa chọn một giải pháp quản lý cơ sở dữ liệu hiệu quả là bước đầu tiên? Và tại sao?
Bước đầu tiên là xác định, ở cấp độ tổ chức, quyền sở hữu dữ liệu và các quy tắc trách nhiệm. Ở cấp độ cơ bản nhất, Billing sở hữu khái niệm về bất kỳ điều gì Khách hàng ở trạng thái Thanh toán Quá hạn và Tiếp thị sở hữu Quyền lợi của Khách hàng. Ý tưởng không phải là tạo ra các kho thông tin trong tổ chức mà là để có sự thừa nhận rõ ràng về các nhu cầu khác nhau. Sau khi hoàn tất, bạn có thể xác định luồng dữ liệu phù hợp trong tổ chức.
Bộ phận Thanh toán sẽ cung cấp quan điểm về Khách hàng cho các thành viên còn lại của tổ chức trong khi vẫn giữ quyền tự do thay đổi cách hình thành của Khách hàng bên trong bộ phận.
Tôi sử dụng bộ phận Lập hóa đơn và Tiếp thị và khái niệm Khách hàng làm ví dụ này để có thể nói về doanh nghiệp trước, điều này rất quan trọng. Để chuyển nó sang một cách kỹ thuật hơn một chút, chúng ta đang nói về các hợp đồng dịch vụ và luồng dữ liệu. Tôi sẽ giới thiệu cho bạn về Ủy quyền của Bezos và cách nó đã biến đổi Amazon. Ý tưởng rất đơn giản:thay vì coi toàn bộ tổ chức là một tổng thể duy nhất, gần như không thể vượt qua một quy mô nhất định, hãy coi nó như một nhóm các tổ chức hợp tác có ranh giới rất rõ ràng giữa chúng.
Khi bạn đã có những ranh giới đó và bạn có ý tưởng tốt về luồng dữ liệu trong tổ chức, bạn có thể yêu cầu các thợ ống nước của bạn đến và thực hiện những việc liên quan đến nó như chuyển hướng luồng dữ liệu đến vị trí trung tâm để phân tích.
Việc có các giao diện được xuất bản như vậy sẽ giúp ích rất nhiều khi đến lúc thay đổi cách một số thứ hoạt động. Miễn là hành vi bên ngoài giống nhau, chúng tôi có thể tự do thay đổi cách xử lý.
3. Trong những năm gần đây, các doanh nghiệp đã áp dụng nhiều loại cơ sở dữ liệu NoSQL. Với việc dữ liệu ngày càng nhạy cảm được lưu trữ trong cơ sở dữ liệu NoSQL, các vấn đề bảo mật ngày càng trở thành mối quan tâm. Việc này của bạn là gì?
Nhìn chung, lý do phổ biến nhất cho việc thiếu bảo mật trong cơ sở dữ liệu NoSQL là do người vận hành sơ suất. Tôi muốn tách bạch rõ ràng hai vấn đề khác biệt ở đây. Chúng tôi có cơ sở dữ liệu NoSQL như Redis, có mô hình bảo mật rõ ràng là chạy trong một môi trường đáng tin cậy. Có một số tính năng bảo mật thô sơ dành cho Redis, nhưng giả định chung là chúng chỉ được sử dụng như tuyến phòng thủ thứ ba hoặc thứ tư.
Các cơ sở dữ liệu NoSQL khác, chẳng hạn như MongoDB, dự kiến sẽ chạy trên các mạng thù địch (tức là Internet). Tuy nhiên, có thể dễ dàng thiết lập MongoDB mà không có bất kỳ bảo mật nào. Về mặt nó, MongoDB có một cấu hình an toàn, cho phép nó chỉ nghe máy cục bộ.
Điều đầu tiên bạn sẽ thấy khi cố gắng kết nối với MongoDB từ xa là hướng dẫn giải thích cách bật quyền truy cập từ xa vào MongoDB mà không cần bất kỳ bảo mật nào.
Ở một mức độ nhất định, đây là sơ suất của nhà điều hành. Nhưng với số lượng tuyệt đối cơ sở dữ liệu MongoDB còn bỏ ngỏ, tôi tin rằng điều này đang rất khó khăn. Ở Trung Quốc, một cơ sở dữ liệu MongoDB mở có hơn 200 triệu CV chỉ chờ ai đó rình mò; một cơ sở dữ liệu được thiết lập không cẩn thận đã khiến các cửa hậu của Nga tiếp xúc với hơn 2.000 công ty.
Với bảo mật, bạn không có cơ hội thứ hai.
Ngược lại, RavenDB sẽ đơn giản từ chối chạy trong một cấu hình dễ bị tấn công. Bạn có thể chạy RavenDB mà không cần bảo mật trên máy cục bộ, nhưng nếu bạn cố gắng đưa cơ sở dữ liệu lên Internet mà không có các biện pháp bảo vệ thích hợp, cơ sở dữ liệu sẽ trả về lỗi giải thích cách bạn nên thiết lập nó đúng cách.
Chúng tôi lấp đầy khoảng trống tối đa bằng cách giả định rằng hầu hết mọi người sẽ thực hiện khối lượng công việc tối thiểu cần thiết và đảm bảo rằng khi điều này xảy ra, trạng thái cuối cùng là tốt, vì vậy chúng tôi đã giúp bạn.
4. Nói về RavenDB, bạn có thể kể tên một số tính năng quan trọng nhất mang lại nhiều giá trị hơn cho khách hàng không? Làm thế nào để RavenDB nổi bật giữa các nhà cung cấp khác về tính năng và hiệu suất?
RavenDB đã chạy trong các hệ thống sản xuất hơn một thập kỷ. Một số tính năng mạnh mẽ nhất mà chúng tôi đã có từ phiên bản gốc. Khả năng phản ứng linh hoạt với môi trường hoạt động là khả năng rõ ràng nhất. RavenDB liên tục phân tích những gì đang diễn ra (truy vấn đến, tải máy chủ, v.v.) và phản ứng với điều đó bằng cách thay đổi phân bổ tài nguyên, cấu trúc nội bộ, v.v. Ý tưởng là thay vì để một DBA toàn thời gian trông coi cơ sở dữ liệu của bạn, thì cơ sở dữ liệu của bạn có thể quản lý công việc của riêng nó.
Khi bắt đầu làm việc trên RavenDB, chúng tôi muốn một cơ sở dữ liệu có tất cả các ưu điểm của cơ sở dữ liệu quan hệ (nhanh, ACID, đáng tin cậy) nhưng không có nhược điểm nào (lược đồ cứng nhắc, bảo trì liên tục, độ phức tạp cao).
Khi chúng tôi bắt đầu, tôi không biết nhiệm vụ này lớn đến mức nào. Trong hơn 10 năm qua, chúng tôi đã có rất nhiều kinh nghiệm trong việc xây dựng một cơ sở dữ liệu có thể hoạt động mà không đòi hỏi bạn phải quan tâm nhiều đến nó. Chúng tôi đã thiết kế RavenDB để giúp chúng tôi triển khai mọi thứ dễ dàng hơn với trọng tâm là hiệu suất. Một điểm chuẩn gần đây trên máy Raspberry Pi (25 đô la, 1 GHz, 1 GB RAM) cho chúng tôi tốc độ hơn 5.000 lần ghi một giây. Trên phần cứng hàng hóa, chúng tôi có thể đạt hơn 100.000 lần viết mỗi giây và hơn 1.000.000 lần đọc mỗi giây.
Tất cả những thứ đó đều nằm trên một nút duy nhất, nhưng RavenDB đã là một cơ sở dữ liệu phân tán ngay từ đầu. Điều này có nghĩa là bạn có thể thiết lập một cụm trong vài phút (tất nhiên là làm như vậy một cách an toàn) và có một hệ thống mạnh mẽ và khả dụng cao.
Chúng tôi cung cấp một số tính năng độc đáo không có ở nơi khác. ETL được tích hợp sẵn bên trong RavenDB và được khách hàng của chúng tôi sử dụng rất nhiều để kích hoạt luồng dữ liệu phong phú. Bạn không cần phải ghép một giải pháp lại với nhau từ các phần khác nhau, tất cả đều có trong hộp và nó hoạt động.
Tính năng Đăng ký là một tính năng mà tôi đặc biệt tự hào. Nó cho phép bạn thực hiện một truy vấn liên tục. Cơ sở dữ liệu ban đầu sẽ cung cấp cho bạn tất cả các kết quả phù hợp với truy vấn của bạn. Vì bạn vẫn đăng ký truy vấn này, cơ sở dữ liệu của bạn sẽ gửi qua bất kỳ tài liệu mới nào phù hợp với truy vấn của bạn khi chúng được nhập hoặc cập nhật để phù hợp với truy vấn đó. Điều này cho phép bạn dễ dàng xây dựng các quy trình kinh doanh mạnh mẽ và hệ thống phụ trợ.
Chúng tôi đã tập trung rất nhiều nỗ lực để biến RavenDB thành một cơ sở dữ liệu đa mô hình có khả năng xử lý tài liệu, khóa-giá trị, dữ liệu nhị phân, bộ đếm phân tán và truy vấn đồ thị.
5. Và cuối cùng, tương lai của hệ quản trị cơ sở dữ liệu là gì? Nó sẽ thay đổi như thế nào trong 3-4 năm tới?
Bạn sẽ thấy tập trung nhiều hơn vào cơ sở dữ liệu đa mô hình. Thay vì phải triển khai một giải pháp chuyên dụng cho từng loại dữ liệu bạn muốn và xử lý sự tích hợp phức tạp giữa từng phần, thị trường đang chuyển sang một giải pháp tích hợp có thể cung cấp đầy đủ các tùy chọn trong một hộp duy nhất.
Đám mây sẽ tiếp tục quan trọng hơn, nhưng tôi sẽ không vội nói lời tạm biệt với các hệ thống phân tán và tại chỗ. Chúng tôi đang thấy rất nhiều khách hàng của chúng tôi thực hiện việc xử lý ngoài lề và trên các hệ thống được kết nối đôi khi. Tôi nghĩ rằng bạn sẽ thấy sự thay đổi trọng tâm, nơi các trung tâm dữ liệu trước đây sẽ chuyển sang đám mây, nhưng rất nhiều quá trình xử lý thực tế sẽ được phân phối ở rìa và trên các thiết bị di động. Điều đó đòi hỏi một cách suy nghĩ khác về phân phối dữ liệu và cách đẩy dữ liệu lên đám mây và lấy dữ liệu từ đám mây.
Sẽ phải chú trọng nhiều hơn đến kiểu xử lý dữ liệu phân tán từng là phạm vi độc quyền của các hệ thống cao cấp.
Chắc chắn sẽ rất thú vị khi xem cảnh quan thay đổi như thế nào và cách chúng tôi xây dựng các công cụ và phương pháp luận để xử lý các chức năng và độ phức tạp ngày càng tăng.
