Tôi đã gặp vài tuyên bố rằng việc sử dụng CacheDB thay vì RDBMS đã được chứng minh. Nhưng tôi không thể hiểu nó tốt hơn RDBMS như thế nào? nếu có, tại sao họ lại bắt đầu với Cache?Bạn đã sử dụng bộ đệm ẩn của Intersystems chưa? Kinh nghiệm của bạn là gì?
Có phải máy chủ RDBMS hoặc Caché không? Bạn có thể viết các ghi chú ngắn gọn về trường hợp sử dụng trong dự án của bạn không?
Cache là một con quái vật độc đáo, tùy thuộc vào cách bạn sử dụng nó thì nó có thể được mô tả như một cơ sở dữ liệu SQL Không, một RDBMS, hoặc một đối tượng cơ sở dữ liệu định hướng. Tất nhiên nó không phải là tất cả mọi thứ cho tất cả mọi người, vì vậy biết được những gì nó là mỗi nhu cầu một số lời giải thích.
Tất cả được xây dựng trên ngôn ngữ thủ tục trước quan hệ được gọi là MUMPS (tên tiếp thị khủng khiếp khủng khiếp đối với Googling, vì vậy giờ đây họ chỉ sử dụng Cache vốn rất khủng khiếp với Googling). Ngôn ngữ này bao gồm các hoạt động để duy trì dữ liệu như các lệnh gốc, do đó, công cụ kiên trì có thể được tối ưu hóa mà không ảnh hưởng đến mã ứng dụng.
Ngôn ngữ này có một loại bộ sưu tập, từ khóa/giá trị với 0 hoặc nhiều khóa được sắp xếp hơn và một loại dữ liệu, có toán tử để thực hiện những điều nghiêm ngặt và những thứ khác. Tất cả các khóa và giá trị là các thể hiện của loại dữ liệu đó.
Điều này đã xảy ra trong khoảng thời gian LONG và các ứng dụng được viết nhiều thập kỷ trên đầu trang vẫn chạy.
Ngôn ngữ này đặt trước RDBMS đầu tiên, nhưng những người thực hiện sau này của ngôn ngữ đã thêm hỗ trợ RDBMS. Bộ nhớ cache biên dịch SQL (tĩnh hoặc động) thành một phiên bản MUMPS hiện đại hơn, sau đó điều khiển công cụ lưu trữ. Nếu điều này nghe có vẻ kỳ lạ thì nó không thực sự - mỗi RDBMS biên dịch hoặc diễn giải SQL thành các hướng dẫn cho công cụ lưu trữ của nó.
Cache đã phát triển thành ngôn ngữ hướng đối tượng (như nhiều ngôn ngữ khác đã thực hiện theo thời gian), có nghĩa là hiện có 2 loại dữ liệu, loại dữ liệu gốc và loại đối tượng. Các đối tượng không thể được lưu trữ dưới dạng khóa hoặc giá trị trên đĩa trực tiếp, nhưng có thể kế thừa hoặc thực hiện các phương thức bền vững.
Vì vậy, những người sử dụng Cache có thể sử dụng mã hướng đối tượng, SQL hoặc mã thủ tục hoặc kết hợp chúng theo ý muốn.
Ưu điểm và nhược điểm là gì?
Đối với những người đang chạy ứng dụng MUMPS cũ, họ khá nhiều không có lựa chọn, vì vậy tôi sẽ tập trung vào mọi người khác.
Một bất lợi lớn là có thị phần nhỏ (so với các RDBMS khác, mặc dù nó có thể được so sánh với các sản phẩm khác thay thế) và có giá trong cùng một ballpark như một RDBMS thương mại (mặc dù nó có thể dễ dàng hơn nhiều để làm việc ra một thỏa thuận cá nhân cho một số sử dụng đặc biệt của nó), do đó, cần phải có một số loại lý do thuyết phục để mua nó.
Ngoài ra, thị phần nhỏ có nghĩa là thị trường nhỏ hơn dành cho nhà phát triển. Ngoài ra, các cách khác nhau có thể được sử dụng có nghĩa là không phải tất cả các nhà phát triển Cache đều phù hợp với tất cả các dự án - ai đó duy trì một ứng dụng di sản (từ trước khi lập trình có cấu trúc) trong 20 năm qua có thể không sử dụng Cache cho web hướng đối tượng các ứng dụng.
Một vấn đề khác là không có nhiều thư viện mã bên ngoài những gì Intersystems (nhà cung cấp) cung cấp, và những người không thể cạnh tranh với một cái gì đó như .NET hoặc Java trong kích thước.
Một lợi thế lớn là Cache Object Script (ngôn ngữ MUMPS hiện đại) có nhiều ngôn ngữ hơn bạn thường nhận được bên trong cơ sở dữ liệu. Đây là một lợi thế hơn logic kinh doanh hơn bạn có trong cơ sở dữ liệu.
Thực ra, IMHO hầu hết các ưu điểm của Cache đều đến nếu bạn sử dụng nó cho logic nghiệp vụ của mình. Kết hợp cơ sở dữ liệu và logic nghiệp vụ của bạn đơn giản hơn nhiều, dễ dàng hơn để có hiệu suất cao và không đặc biệt dẫn đến các vấn đề bảo trì lâu dài khi môi trường hỗ trợ nó nhiều. Nhược điểm của việc kết hợp cơ sở dữ liệu và logic nghiệp vụ trong Cache là việc chuyển đổi hoặc sẽ khá khó khăn, và thường logic nghiệp vụ của bạn được viết bằng ngôn ngữ miễn phí và bạn không cần bất kỳ loại giấy phép nào để chạy nó. Quay lại đầu trang Ở đây bạn đang khá nhiều trong cùng một thuyền như thể logic kinh doanh của bạn là trong TSQL, ngoại trừ nó thậm chí còn khó khăn hơn để cổng.
Nếu bạn là O.K. với điều đó, mặc dù, nhiều điều đáng yêu. Không có ORM - thương mại hoặc mã hóa bằng tay. SQL được biên dịch thành mã mà bạn có thể xem (nó được tạo ra để nó được tối ưu hóa cho tốc độ đọc và tên biến có thể là những thứ như 'T32', nhưng nó vẫn có thể đọc được nếu bạn phải), thậm chí là bước qua hoặc điểm ngắt. Chi phí viết các con trỏ SQL rất thấp. Bạn thực sự có thể viết mã hướng đối tượng. Nó được giải thích, vì vậy nó dễ dàng phát triển nhanh hơn. Nếu bạn muốn tốc độ bạn có thể tắt các giao dịch và không có SQL.
Tôi cũng thấy rất dễ quản lý. Trong hầu hết các kinh nghiệm của tôi với nó không có điều như một DBA - bạn chỉ cần không có một.
Cache của hệ thống liên kết có thể được định nghĩa là Cơ sở dữ liệu hướng đối tượng.
Cách tôi nghĩ về nó là nó là cơ sở dữ liệu RDBMS thông thường với công cụ tạo kịch bản hướng đối tượng. Oracle đã lưu trữ procs, Cache có Object script.
Chúng tôi đang di chuyển sang bộ đệm ẩn Intersystems để tận dụng lợi thế của các công cụ báo cáo BI & của họ. Tôi vẫn chưa chạy qua một tình huống mà không thể được giải quyết với thủ tục lưu trữ của MySQL hoặc Oracle được nêu ra. Tôi thích viết mọi thứ trong các thủ tục SQL để tránh bất kỳ sự đau đầu di trú nào trong tương lai.
Những người có nền hướng đối tượng mạnh có thể thích sử dụng ObjectScript hơn.
Chỉ trong trường hợp bạn chưa nhìn thấy nó, đây là their documentation
Nó không phải là RDBMS theo thiết kế. Nó là cơ sở dữ liệu đối tượng. bạn có thể sử dụng giao diện sql, và xem dữ liệu như đến từ RDBMS truyền thống.
Tôi đã thử cách đây vài năm, chỉ dành cho dự án sở thích, chủ yếu là học tập.
Một điều đáng chú ý là trước khi 'tất cả những thứ trên đám mây' mà họ đã có hệ thống, nơi bạn có thể lưu trữ dữ liệu qua một nút và nó sẽ sao chép dữ liệu cho một số nút khác. Vì vậy, nếu bạn cần mở rộng quy mô, nó có thể được thực hiện. Đó là cca cách đây 10 năm khi nhân rộng dữ liệu giữa các cơ sở dữ liệu được thực hiện bằng các công cụ trong nhà, afaik. Họ tuyên bố có hệ thống với 50k cộng với những người làm việc trực tuyến với một cơ sở. Nhân rộng có thể được thực hiện bằng nhiều cách.
Dữ liệu được lưu trữ trong cây, chúng gọi là hình cầu. Và mọi thứ bạn lưu trữ là cây. Họ có đối tượng truy cập, thực sự đối tượng trong cơ sở dữ liệu là các đối tượng trong ngôn ngữ của bạn (Objectcript, tôi nghĩ rằng họ đã hỗ trợ cho java). Có thừa kế thực sự trong dữ liệu (globals, gọi nó là bảng sẽ không chính xác). Vì vậy, không cần cho công cụ ngủ đông/orm/jpa/....
Ngôn ngữ là hmm. Nếu bạn thích Perl một lót, bạn là tốt. Nếu không nó là chalenging.
Tôi không đồng ý với nhận xét cuối cùng rằng không có DBA. Nó chỉ là bình thường được bổ sung trong vai trò của nhóm lập trình, mà phải làm nhiệm vụ DBA chung. Trong công ty của tôi vai trò DBA về cơ bản được chia giữa 3 người 1 chương trình DB thay đổi, 1 triển khai những thay đổi khác duy trì điều chỉnh sao lưu và hiệu suất. Vì có rất ít công cụ hiệu suất, chúng tôi đã phải thuê Intersystems nhiều lần để thực hiện các nhiệm vụ tối ưu hóa DBA. Những bất lợi chính là lập trình viên bộ nhớ Cache là rất hiếm và do đó chi phí bảo trì sản phẩm tăng lên về mặt này. – Andrew
@Andrew - Tôi chỉ có thể đi theo những gì tôi đã trải nghiệm hoặc nghe người ta nói, và có lẽ đó là không điển hình. Tôi chưa bao giờ có nhiều công việc như bạn mô tả về triển khai, sao lưu và điều chỉnh hiệu suất. Nhưng tôi đồng ý rằng có rất ít công cụ hiệu suất và lập trình viên rất hiếm. – psr
Cũng trong một ý nghĩa tôi sẽ nói giống nhau về MySQL, MS SQL, vv Tôi biết rất nhiều tổ chức có một hoặc nhiều cơ sở dữ liệu đang chạy mà không có một DBA. Bạn có xu hướng tìm "nhu cầu" cho một DBA dựa trên kích thước dữ liệu bạn đang làm việc, tần suất cập nhật và mức độ quan trọng của nó (và có lẽ quan trọng hơn là nhận thức) đối với công ty của bạn. Chúng tôi có một cơ sở dữ liệu Cache và 2 người thực hiện các nhiệm vụ DBA. Chúng tôi có rất nhiều cơ sở dữ liệu MySQL sau khi thiết lập đã có sự tham gia của 0 DBA. – Andrew