3. Các biến thể của cấu trúc khi sử dụng toàn cục
Một cấu trúc như cây có thứ tự có nhiều trường hợp đặc biệt. Hãy xem xét những thứ có giá trị thực tế khi làm việc với toàn cầu.
3.1 Trường hợp đặc biệt 1. Một nút không có nhánh
Globals có thể được sử dụng không chỉ như một mảng mà còn như các biến thông thường. Ví dụ: với tư cách là một bộ đếm:
Set ^counter = 0 ; установка счётчика
Set id=$Increment(^counter) ; атомарное инкрементированиеTrong trường hợp này, toàn cầu, ngoài ý nghĩa của nó, còn có thể có các nhánh. Cái này không loại trừ cái kia.
3.2 Trường hợp đặc biệt 2. Một đỉnh và nhiều nhánh
Nói chung, đây là cơ sở khóa-giá trị cổ điển. Và nếu chúng ta lưu một bộ giá trị làm giá trị, chúng ta sẽ nhận được một bảng rất bình thường với khóa chính.
Để triển khai một bảng trên toàn cục, chúng ta sẽ phải tự tạo các hàng từ các giá trị cột, sau đó lưu chúng vào toàn cục bằng khóa chính. Để có thể chia lại chuỗi thành các cột khi đọc, bạn có thể sử dụng:
- ký tự phân cách.
Set ^t(id1) = "col11/col21/col31" Set ^t(id2) = "col12/col22/col32" - một sơ đồ cứng nhắc trong đó mỗi trường chiếm một số byte được xác định trước. Như được thực hiện trong cơ sở dữ liệu quan hệ.
- một hàm đặc biệt $LB (có sẵn trong Cache), tạo ra một chuỗi giá trị.
Set ^t(id1) = $LB("col11", "col21", "col31") Set ^t(id2) = $LB("col12", "col22", "col32")
Điều thú vị là không khó để sử dụng toàn cục để làm điều gì đó tương tự như chỉ mục phụ trong cơ sở dữ liệu quan hệ. Hãy gọi các cấu trúc như vậy là chỉ mục toàn cầu. Chỉ mục toàn cục là một cây phụ trợ để tìm kiếm nhanh các trường không thuộc khóa chính của toàn cục chính. Để điền và sử dụng nó, bạn cần viết mã bổ sung.
Hãy tạo một chỉ mục toàn cầu trên cột đầu tiên.
Set ^i("col11", id1) = 1
Set ^i("col12", id2) = 1Bây giờ, để tìm kiếm nhanh thông tin ở cột đầu tiên, chúng ta phải nhìn vào tổng thể ^i và tìm các khóa chính (id) tương ứng với giá trị mong muốn của cột đầu tiên.
Khi chèn một giá trị, chúng ta có thể tạo ngay cả giá trị toàn cục và chỉ mục cho các trường bắt buộc. Và để đảm bảo độ tin cậy, hãy gói gọn tất cả trong một giao dịch.
TSTART
Set ^t(id1) = $LB("col11", "col21", "col31")
Set ^i("col11", id1) = 1
TCOMMITChi tiết cách thực hiện trên M , .
Các bảng như vậy sẽ hoạt động nhanh như trong cơ sở dữ liệu truyền thống (hoặc thậm chí nhanh hơn) nếu các hàm chèn/cập nhật/xóa hàng được viết bằng COS/M và được biên dịch.Tôi đã kiểm tra câu lệnh này bằng các thử nghiệm trên INSERT và SELECT hàng loạt vào một bảng hai cột, bao gồm cả việc sử dụng các lệnh TSTART và TCOMMIT (giao dịch).
Tôi chưa thử nghiệm các kịch bản phức tạp hơn với truy cập đồng thời và giao dịch song song.
Nếu không sử dụng giao dịch, tốc độ chèn là 778 lần chèn/giây trên một triệu giá trị.
Với 300 triệu giá trị - 422 lần chèn/giây.
Khi sử dụng giao dịch - 572 lần chèn/giây cho lần chèn 082M. Tất cả các hoạt động được thực hiện từ mã M được biên dịch.
Ổ cứng là loại thường chứ không phải SSD. RAID5 có chức năng ghi lại. Bộ xử lý Phenom II 1100T.
Để kiểm tra cơ sở dữ liệu SQL theo cách tương tự, bạn cần viết một thủ tục lưu sẵn để thực hiện việc chèn vào một vòng lặp. Khi kiểm tra MySQL 5.5 (bộ lưu trữ InnoDB), bằng phương pháp này, tôi nhận được số lượng chèn không quá 11K mỗi giây.
Có, việc triển khai các bảng trên toàn cục có vẻ phức tạp hơn trong cơ sở dữ liệu quan hệ. Do đó, cơ sở dữ liệu công nghiệp trên toàn cầu có quyền truy cập SQL để đơn giản hóa công việc với dữ liệu dạng bảng.
Nói chung, nếu lược đồ dữ liệu không thay đổi thường xuyên, tốc độ chèn không quan trọng và toàn bộ cơ sở dữ liệu có thể được biểu diễn dễ dàng dưới dạng bảng chuẩn hóa thì làm việc với SQL sẽ dễ dàng hơn vì nó cung cấp mức độ trừu tượng cao hơn .
Trong trường hợp cụ thể này tôi muốn chứng tỏ rằng toàn cầu có thể hoạt động như một hàm tạo để tạo các cơ sở dữ liệu khác. Giống như một trình biên dịch chương trình có thể viết các ngôn ngữ khác. Dưới đây là ví dụ về cách bạn có thể tạo các chất tương tự trên toàn cầu
Nếu bạn cần tạo một số loại cơ sở dữ liệu không chuẩn với nỗ lực tối thiểu, thì bạn nên hướng tới toàn cầu.
3.3 Trường hợp đặc biệt 3. Cây hai cấp, mỗi nút cấp XNUMX có số nhánh cố định
Có thể bạn đã đoán ra: đây là một cách triển khai thay thế các bảng trên toàn cục. Hãy so sánh việc thực hiện này với việc thực hiện trước đó.
Các bảng trên cây hai cấp so với cây hai cấp trên cây một cấp.
Nhược điểm
Ưu điểm
- Việc chèn chậm hơn vì bạn cần đặt số nút bằng số cột.
- Tiêu thụ nhiều dung lượng ổ đĩa hơn. Vì các chỉ mục chung (được hiểu là chỉ mục mảng) có tên cột chiếm dung lượng ổ đĩa và được nhân đôi cho mỗi hàng.
- Truy cập nhanh hơn vào các giá trị của từng cột riêng lẻ vì không cần phân tích chuỗi. Theo thử nghiệm của tôi, nó nhanh hơn 11,5% trên 2 cột và hơn thế nữa trên số lượng cột lớn hơn.
- Dễ dàng thay đổi lược đồ dữ liệu hơn
- Mã rõ ràng hơn
Kết luận: không phải cho tất cả mọi người. Vì tốc độ là một trong những lợi ích chính của toàn cầu nên việc sử dụng cách triển khai này không có ý nghĩa gì vì rất có thể nó sẽ hoạt động không nhanh hơn các bảng trong cơ sở dữ liệu quan hệ.
3.4 Trường hợp chung. Cây và cây có trật tự
Bất kỳ cấu trúc dữ liệu nào có thể được biểu diễn dưới dạng cây đều phù hợp hoàn hảo với hình cầu.
3.4.1 Đối tượng có đối tượng con
Đây là lĩnh vực sử dụng truyền thống của toàn cầu. Trong lĩnh vực y tế có rất nhiều bệnh, thuốc, triệu chứng và phương pháp điều trị. Thật không hợp lý khi tạo một bảng có hàng triệu trường cho mỗi bệnh nhân. Hơn nữa, 99% trường sẽ trống.
Hãy tưởng tượng một cơ sở dữ liệu SQL gồm các bảng: “bệnh nhân” ~ 100 trường, “Thuốc” - 000 trường, “Trị liệu” - 100 trường, “Biến chứng” - 000 trường, v.v. và như thế. Hoặc bạn có thể tạo cơ sở dữ liệu gồm hàng nghìn bảng, mỗi bảng dành cho một loại bệnh nhân cụ thể (và chúng có thể chồng lên nhau!), phương pháp điều trị, thuốc và hàng nghìn bảng khác để kết nối giữa các bảng này.
Hình cầu rất lý tưởng cho y học vì chúng cho phép bạn tạo cho mỗi bệnh nhân một bản mô tả chính xác về tiền sử bệnh của họ, các liệu pháp khác nhau và tác dụng của thuốc, dưới dạng cây mà không lãng phí thêm dung lượng đĩa trên các cột trống, như thường lệ. là trường hợp trong một trường hợp quan hệ.
Sử dụng toàn cục sẽ thuận tiện để tạo cơ sở dữ liệu với dữ liệu về con người, khi điều quan trọng là phải tích lũy và hệ thống hóa tối đa các thông tin khác nhau về khách hàng. Đây là nhu cầu trong y học, ngân hàng, tiếp thị, lưu trữ và các lĩnh vực khác
.
Tất nhiên, trong SQL bạn cũng có thể mô phỏng một cây chỉ bằng một vài bảng (, ,,,,,,,,,), tuy nhiên việc này phức tạp hơn đáng kể và sẽ chậm hơn. Về cơ bản, bạn sẽ phải viết một toàn cục hoạt động trên các bảng và ẩn tất cả công việc với các bảng dưới một lớp trừu tượng. Việc mô phỏng công nghệ cấp thấp hơn (toàn cầu) bằng công nghệ cấp cao hơn (SQL) là sai. Không phù hợp.
Không có gì bí mật khi việc thay đổi lược đồ dữ liệu trên các bảng khổng lồ (ALTER TABLE) có thể mất một khoảng thời gian khá lớn. Ví dụ: MySQL thực hiện ALTER TABLE ADD|DROP COLUMN bằng cách sao chép hoàn toàn thông tin từ bảng cũ sang bảng mới (các công cụ MyISAM, InnoDB đã được thử nghiệm). Điều này có thể treo một cơ sở dữ liệu đang hoạt động với hàng tỷ bản ghi trong nhiều ngày, nếu không muốn nói là vài tuần.
Việc thay đổi cấu trúc dữ liệu nếu chúng ta sử dụng toàn cầu không tốn kém gì. Bất cứ lúc nào, chúng ta có thể thêm bất kỳ thuộc tính mới nào mà chúng ta cần vào bất kỳ đối tượng nào, ở bất kỳ cấp độ phân cấp nào. Những thay đổi liên quan đến việc đổi tên các nhánh có thể được chạy ở chế độ nền trên cơ sở dữ liệu đang chạy.
Do đó, khi nói đến việc lưu trữ các đối tượng với số lượng lớn các thuộc tính tùy chọn, toàn cục là một lựa chọn tuyệt vời.
Hơn nữa, hãy để tôi nhắc bạn rằng quyền truy cập vào bất kỳ thuộc tính nào là ngay lập tức, vì trong toàn cục, tất cả các đường dẫn đều là cây B.
Cơ sở dữ liệu toàn cầu nói chung là một loại cơ sở dữ liệu hướng tài liệu với khả năng lưu trữ thông tin phân cấp. Do đó, cơ sở dữ liệu hướng tài liệu có thể cạnh tranh với cơ sở dữ liệu toàn cầu trong lĩnh vực lưu trữ hồ sơ y tế. Nhưng nó vẫn không hoàn toàn giống nhauHãy lấy MongoDB để so sánh. Trong miền này nó thua toàn cầu vì những lý do sau:
- Kích thước tài liệu. Đơn vị lưu trữ là văn bản ở định dạng JSON (chính xác hơn là BSON) với dung lượng tối đa khoảng 16MB. Hạn chế này được thực hiện cụ thể để cơ sở dữ liệu JSON không bị chậm trong quá trình phân tích cú pháp nếu một tài liệu JSON khổng lồ được lưu trữ trong đó và sau đó được các trường truy cập. Tài liệu này phải chứa tất cả thông tin về bệnh nhân. Tất cả chúng ta đều biết hồ sơ bệnh nhân dày đến mức nào. Kích thước thẻ tối đa 16 MB ngay lập tức chấm dứt việc bệnh nhân có thẻ bệnh bao gồm các tệp MRI, chụp X-quang và các nghiên cứu khác. Trong một nhánh của thế giới, bạn có thể có hàng gigabyte và terabyte thông tin. Về nguyên tắc, chúng ta có thể chấm dứt việc này, nhưng tôi sẽ tiếp tục.
- Thời gian ý thức/thay đổi/xóa các thuộc tính mới trong biểu đồ của bệnh nhân. Cơ sở dữ liệu như vậy phải đọc toàn bộ bản đồ vào bộ nhớ (đây là một lượng lớn!), phân tích BSON, thêm/thay đổi/xóa nút mới, cập nhật chỉ mục, đóng gói vào BSON và lưu vào đĩa. Toàn cầu chỉ cần truy cập vào một thuộc tính cụ thể và thao tác với nó.
- Truy cập nhanh vào các thuộc tính riêng lẻ. Với nhiều thuộc tính trong một tài liệu và cấu trúc đa cấp của nó, việc truy cập vào các thuộc tính riêng lẻ sẽ nhanh hơn do mỗi đường dẫn trong toàn cục là một cây B. Trong BSON, bạn phải phân tích tài liệu một cách tuyến tính để tìm thuộc tính mong muốn.
3.3.2 Mảng kết hợp
Mảng kết hợp (ngay cả với mảng lồng nhau) hoàn toàn phù hợp trên toàn cầu. Ví dụ: một mảng như vậy từ PHP sẽ được hiển thị trong hình 3.3.1 đầu tiên.
$a = array(
"name" => "Vince Medvedev",
"city" => "Moscow",
"threatments" => array(
"surgeries" => array("apedicectomy", "biopsy"),
"radiation" => array("gamma", "x-rays"),
"physiotherapy" => array("knee", "shoulder")
)
);3.3.3 Tài liệu phân cấp: XML, JSON
Cũng dễ dàng được lưu trữ trong toàn cầu. Có thể được bố trí theo nhiều cách khác nhau để lưu trữ.
XML
Cách dễ nhất để phân tách XML thành toàn cục là lưu trữ các thuộc tính thẻ trong các nút. Và nếu cần truy cập nhanh vào các thuộc tính thẻ thì chúng ta có thể chuyển chúng thành các nhánh riêng biệt.
<note id=5>
<to>Вася</to>
<from>Света</from>
<heading>Напоминание</heading>
<body>Позвони мне завтра!</body>
</note>Trên COS, điều này sẽ tương ứng với mã:
Set ^xml("note")="id=5"
Set ^xml("note","to")="Саша"
Set ^xml("note","from")="Света"
Set ^xml("note","heading")="Напоминание"
Set ^xml("note","body")="Позвони мне завтра!"Bình luận: Đối với XML, JSON, mảng kết hợp, bạn có thể nghĩ ra nhiều cách hiển thị khác nhau trên toàn cầu. Trong trường hợp này, chúng tôi không phản ánh thứ tự của các thẻ phụ trong thẻ ghi chú. Trên toàn cầu ^xml thẻ phụ sẽ được hiển thị theo thứ tự bảng chữ cái. Để phản ánh đúng thứ tự, bạn có thể sử dụng, ví dụ: màn hình sau:
JSON.
Hình ảnh đầu tiên từ phần 3.3.1 hiển thị hình ảnh phản ánh của tài liệu JSON này:
var document = {
"name": "Vince Medvedev",
"city": "Moscow",
"threatments": {
"surgeries": ["apedicectomy", "biopsy"],
"radiation": ["gamma", "x-rays"],
"physiotherapy": ["knee", "shoulder"]
},
};3.3.4 Các cấu trúc giống hệt nhau được kết nối bởi các mối quan hệ thứ bậc
Ví dụ: cấu trúc của văn phòng bán hàng, vị trí của mọi người trong cấu trúc MLM, cơ sở dữ liệu về các thế cờ trong cờ vua.
Ra mắt cơ sở dữ liệu. Bạn có thể sử dụng ước tính lực hành trình làm giá trị chỉ số của nút chung. Khi đó, để chọn nước đi mạnh nhất, chỉ cần chọn nhánh có trọng số lớn nhất là đủ. Trên toàn cầu, tất cả các nhánh ở mỗi cấp sẽ được sắp xếp theo cường độ di chuyển.
Cơ cấu phòng kinh doanh, cơ cấu con người trong MLM. Các nút có thể lưu trữ các giá trị bộ nhớ đệm nhất định phản ánh đặc điểm của toàn bộ cây con. Ví dụ: khối lượng bán hàng của một cây con nhất định. Bất cứ lúc nào chúng ta cũng có thể nhận được một con số phản ánh thành tích của bất kỳ chi nhánh nào.
4. Sử dụng Globals trong trường hợp nào là có lợi nhất?
Cột đầu tiên trình bày các trường hợp trong đó bạn sẽ đạt được tốc độ tăng đáng kể bằng cách sử dụng toàn cầu và cột thứ hai khi thiết kế hoặc mô hình dữ liệu sẽ được đơn giản hóa.
tốc độ
Dễ dàng xử lý/trình bày dữ liệu
- Chèn [với tính năng tự động sắp xếp theo từng cấp độ], [lập chỉ mục theo khóa chính]
- Loại bỏ cây con
- Các đối tượng có nhiều thuộc tính lồng nhau yêu cầu quyền truy cập riêng lẻ
- Cấu trúc phân cấp với khả năng bỏ qua các nhánh con từ bất kỳ nhánh nào, ngay cả những nhánh không tồn tại
- Truyền tải theo chiều sâu của cây con
- Các đối tượng/thực thể có số lượng lớn các thuộc tính/thực thể tùy chọn [và/hoặc lồng nhau]
- Dữ liệu không có lược đồ. Khi những thuộc tính mới thường có thể xuất hiện và những thuộc tính cũ biến mất.
- Bạn cần tạo một cơ sở dữ liệu tùy chỉnh.
- Cơ sở đường dẫn và cây quyết định. Khi thuận tiện để biểu diễn các đường dẫn dưới dạng cây.
- Loại bỏ cấu trúc phân cấp mà không sử dụng đệ quy
Extension .
Từ chối trách nhiệm: Bài viết này và những bình luận của tôi về nó là quan điểm của tôi và không liên quan đến quan điểm chính thức của InterSystems Corporation.
Nguồn: www.habr.com