Những vấn đề về khả năng mở rộng mà bạn gặp phải khi sử dụng kho dữ liệu NoQuery? [đóng cửa]

NoQuery đề cập đến các cửa hàng dữ liệu không liên quan phá vỡ lịch sử của cơ sở dữ liệu quan hệ và đảm bảo ACID. Các cửa hàng dữ liệu NoQuery mã nguồn mở phổ biến bao gồm:

• Cassandra (dạng bảng, được viết bằng Java, được sử dụng bởi Cisco, WebEx, Digg, Facebook, IBM, Mahalo, Rackspace, Reddit và Twitter)
• CouchDB (tài liệu, được viết bằng Erlang, được sử dụng bởi BBC và Engine Yard)
• Dynomite (khóa-giá trị, được viết bằng Erlang, được sử dụng bởi Powerset)
• HBase (khóa-giá trị, được viết bằng Java, được Bing sử dụng)
• Hypertable (dạng bảng, được viết bằng C ++, được sử dụng bởi Baidu)
• Kai (khóa-giá trị, được viết bằng Erlang)
• MemcacheDB (khóa-giá trị, được viết bằng C, được sử dụng bởi Reddit)
• MongoDB (tài liệu, được viết bằng C ++, được sử dụng bởi Electronic Arts, Github, NY Times và Sourceforge)
• Neo4j (biểu đồ, được viết bằng Java, được sử dụng bởi một số trường đại học Thụy Điển)
• Dự án Voldemort (khóa-giá trị, được viết bằng Java, được sử dụng bởi LinkedIn)
• Redis (khóa-giá trị, được viết bằng C, được sử dụng bởi Craigslist, Engine Yard và Github)
• Riak (khóa-giá trị, được viết bằng Erlang, được sử dụng bởi Comcast và Mochi Media)
• Ringo (khóa-giá trị, được viết bằng Erlang, được Nokia sử dụng)
• Scalaris (khóa-giá trị, được viết bằng Erlang, được sử dụng bởi OnScale)
• Terrastore (tài liệu, viết bằng Java)
• ThruDB (tài liệu, được viết bằng C ++, được sử dụng bởi JunkDepot.com)
• Nội các Tokyo / Tokyo Tyrant (khóa-giá trị, được viết bằng C, được sử dụng bởi Mixi.jp (trang mạng xã hội Nhật Bản))

Tôi muốn biết về các vấn đề cụ thể mà bạn - trình đọc SO - đã giải quyết bằng cách sử dụng kho lưu trữ dữ liệu và kho lưu trữ dữ liệu NoQuery mà bạn đã sử dụng.

Câu hỏi:

• Những vấn đề về khả năng mở rộng nào bạn đã sử dụng kho dữ liệu NoQuery để giải quyết?
• Cửa hàng dữ liệu NoQuery nào bạn đã sử dụng?
• Cơ sở dữ liệu nào bạn đã sử dụng trước khi chuyển sang kho dữ liệu NoQuery?

Tôi đang tìm kiếm trải nghiệm trực tiếp, vì vậy xin vui lòng không trả lời trừ khi bạn có điều đó.

Tôi đã chuyển một tiểu dự án nhỏ từ MySQL sang CouchDB, để có thể xử lý tải. Kết quả thật tuyệt vời.

Khoảng 2 năm trước, chúng tôi đã phát hành một phần mềm tự viết trên http://www.ubfoxusers.de/ (có lẽ là trang web cộng đồng Linux lớn nhất của Đức). Trang web được viết bằng Python và chúng tôi đã thêm một phần mềm trung gian WSGI có thể nắm bắt tất cả các ngoại lệ và gửi chúng đến một trang web nhỏ khác do MySQL cung cấp. Trang web nhỏ này đã sử dụng hàm băm để xác định các lỗi khác nhau và lưu trữ số lần xuất hiện cũng như lần xuất hiện cuối cùng.

Thật không may, ngay sau khi phát hành, trang web tracBack-logger đã không phản hồi nữa. Chúng tôi đã có một số vấn đề khóa với db sản xuất của trang web chính của chúng tôi, điều này đã đưa ra các ngoại lệ gần như mọi yêu cầu, cũng như một số lỗi khác mà chúng tôi chưa khám phá trong giai đoạn thử nghiệm. Cụm máy chủ của trang web chính của chúng tôi, được gọi là trang gửi tracBack-logger vài k lần mỗi giây. Và đó là một cách quá nhiều cho máy chủ nhỏ lưu trữ bộ ghi nhật ký theo dõi (nó đã là một máy chủ cũ, chỉ được sử dụng cho mục đích phát triển).

Tại thời điểm này, CouchDB khá phổ biến, và vì vậy tôi đã quyết định dùng thử và viết một bộ ghi nhật ký nhỏ với nó. Trình ghi nhật ký mới chỉ bao gồm một tệp python duy nhất, cung cấp danh sách lỗi với các tùy chọn sắp xếp và bộ lọc và trang gửi. Và trong nền tôi đã bắt đầu một quy trình CouchDB. Phần mềm mới đáp ứng cực kỳ nhanh chóng cho tất cả các yêu cầu và chúng tôi có thể xem số lượng lớn các báo cáo lỗi tự động.

Một điều thú vị là, giải pháp trước đây, đang chạy trên một máy chủ chuyên dụng cũ, mặt khác, trang web dựa trên CouchDB mới chỉ chạy trên một cá thể xen được chia sẻ với nguồn lực rất hạn chế. Và tôi thậm chí đã không sử dụng sức mạnh của các cửa hàng khóa-giá trị để mở rộng theo chiều ngang. Khả năng của CouchDB / Erlang OTP để xử lý các yêu cầu đồng thời mà không khóa bất cứ thứ gì đã đủ để phục vụ nhu cầu.

Bây giờ, trình ghi nhật ký CouchDB-tracBack được viết nhanh vẫn đang chạy và là một cách hữu ích để khám phá các lỗi trên trang web chính. Dù sao, khoảng một tháng một lần cơ sở dữ liệu trở nên quá lớn và quá trình CouchDB bị giết. Nhưng sau đó, lệnh db-compact của CouchDB làm giảm kích thước từ vài GB xuống một số KB một lần nữa và cơ sở dữ liệu sẽ hoạt động trở lại (có lẽ tôi nên xem xét thêm một cronjob ở đó ... 0o).

Tóm lại, CouchDB chắc chắn là lựa chọn tốt nhất (hoặc ít nhất là lựa chọn tốt hơn so với MySQL) cho tiểu dự án này và nó hoạt động tốt.

Dự án hiện tại của tôi thực sự.

Lưu trữ 18.000 đối tượng trong cấu trúc được chuẩn hóa: 90.000 hàng trên 8 bảng khác nhau. Mất 1 phút để truy xuất và ánh xạ chúng vào mô hình đối tượng Java của chúng tôi, đó là với mọi thứ được lập chỉ mục chính xác, v.v.

Lưu trữ chúng dưới dạng cặp khóa / giá trị bằng cách sử dụng biểu diễn văn bản nhẹ: 1 bảng, 18.000 hàng, 3 giây để truy xuất tất cả chúng và xây dựng lại các đối tượng Java.

Trong điều khoản kinh doanh: lựa chọn đầu tiên là không khả thi. Tùy chọn thứ hai có nghĩa là ứng dụng của chúng tôi hoạt động.

Chi tiết công nghệ: chạy trên MySQL cho cả SQL và NoQuery! Gắn bó với MySQL để hỗ trợ giao dịch tốt, hiệu suất và hồ sơ theo dõi đã được chứng minh là không làm hỏng dữ liệu, mở rộng khá tốt, hỗ trợ phân cụm, v.v.

Mô hình dữ liệu của chúng tôi trong MySQL hiện chỉ là các trường chính (số nguyên) và trường "giá trị" lớn: về cơ bản chỉ là một trường văn bản lớn.

Chúng tôi đã không đi với bất kỳ người chơi mới nào (CouchDB, Cassandra, MongoDB, v.v.) bởi vì mặc dù mỗi người đều cung cấp các tính năng / hiệu suất tuyệt vời theo cách riêng của họ, luôn có những hạn chế đối với hoàn cảnh của chúng tôi (ví dụ như hỗ trợ Java thiếu / chưa trưởng thành).

Lợi ích bổ sung của (ab) sử dụng MySQL - các bit của mô hình của chúng tôi rằng làm việc relationally có thể dễ dàng kết nối với dữ liệu lưu trữ chìa khóa / giá trị của chúng tôi.

Cập nhật: đây là một ví dụ về cách chúng tôi trình bày nội dung văn bản, không phải miền kinh doanh thực tế của chúng tôi (chúng tôi không làm việc với "sản phẩm") khi ông chủ của tôi bắn tôi, nhưng truyền đạt ý tưởng, bao gồm cả khía cạnh đệ quy (một thực thể, ở đây một sản phẩm, "chứa" những người khác). Hy vọng rằng rõ ràng làm thế nào trong một cấu trúc được chuẩn hóa, đây có thể là một vài bảng, ví dụ như tham gia một sản phẩm vào phạm vi hương vị của nó, mà các sản phẩm khác được chứa, v.v.

Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]

Todd Hoff là highscalability.com có rất nhiều bảo hiểm lớn của NoSQL, trong đó có một số nghiên cứu tình huống.

DBMS cột Vertica thương mại có thể phù hợp với mục đích của bạn (mặc dù nó hỗ trợ SQL): nó rất nhanh so với các DBMS quan hệ truyền thống cho các truy vấn phân tích. Xem Stonoplker, giấy CACM gần đây của cộng sự tương phản với Vertica với bản đồ thu nhỏ.

Cập nhật: Và Cassandra đã chọn Twitter trên một số người khác, bao gồm HBase, Voldemort, MongoDB, MemcacheDB, Redis và HyperTable.

Cập nhật 2: Rick Cattell vừa công bố so sánh một số hệ thống NoQuery trong Cửa hàng dữ liệu hiệu suất cao . Và highscalability.com hãy xem bài viết của Rick ở đây .

Chúng tôi đã chuyển một phần dữ liệu của mình từ mysql sang mongodb, không nhiều cho khả năng mở rộng nhưng nhiều hơn vì nó phù hợp hơn cho các tệp và dữ liệu không phải là bảng.

Trong sản xuất chúng tôi hiện đang lưu trữ:

• 25 nghìn tệp (60 GB)
• 130 triệu "tài liệu" khác (350GB)

với doanh thu hàng ngày khoảng 10 GB.

Cơ sở dữ liệu được triển khai theo cấu hình "ghép nối" trên hai nút (6x450GB sas raid10) với các máy khách apache / wsgi / python bằng api mongodb python (pymongo). Thiết lập đĩa có thể là quá mức cần thiết nhưng đó là những gì chúng ta sử dụng cho mysql.

Ngoài một số vấn đề với luồng chủ đề pymongo và tính chất chặn của máy chủ mongodb, nó đã là một kinh nghiệm tốt.

Tôi xin lỗi vì đã đi ngược lại văn bản in đậm của bạn, vì tôi không có kinh nghiệm trực tiếp nào, nhưng bộ bài đăng trên blog này là một ví dụ điển hình về việc giải quyết vấn đề với CouchDB.

CouchDB: Một trường hợp nghiên cứu

Về cơ bản, ứng dụng textme đã sử dụng CouchDB để xử lý vấn đề dữ liệu bùng nổ của họ. Họ thấy rằng SQL quá chậm để xử lý một lượng lớn dữ liệu lưu trữ và đã chuyển nó sang CouchDB. Đây là một bài đọc tuyệt vời và anh ấy thảo luận về toàn bộ quá trình tìm ra những vấn đề mà CouchDB có thể giải quyết và cách họ giải quyết chúng.

Chúng tôi đã chuyển một số dữ liệu của chúng tôi, chúng tôi đã sử dụng để lưu trữ trong Postgresql và Memcached vào Redis . Các cửa hàng giá trị khóa phù hợp hơn nhiều để lưu trữ dữ liệu đối tượng phân cấp. Bạn có thể lưu trữ dữ liệu blob nhanh hơn nhiều và với thời gian và nỗ lực phát triển ít hơn nhiều so với sử dụng ORM để ánh xạ blob của bạn tới RDBMS.

Tôi có một máy khách c # redis mã nguồn mở cho phép bạn lưu trữ và truy xuất bất kỳ đối tượng POCO nào với 1 dòng:

var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });

Các cửa hàng giá trị khóa cũng dễ dàng hơn để 'mở rộng quy mô' khi bạn có thể thêm một máy chủ mới và sau đó phân vùng tải của bạn đồng đều để bao gồm máy chủ mới. Điều quan trọng, không có máy chủ trung tâm sẽ giới hạn khả năng mở rộng của bạn. (mặc dù bạn vẫn sẽ cần một chiến lược để băm nhất quán để phân phối các yêu cầu của bạn).

Tôi coi Redis là một 'tệp văn bản được quản lý' trên các steroid cung cấp quyền truy cập nhanh, đồng thời và nguyên tử cho nhiều khách hàng, vì vậy mọi thứ tôi từng sử dụng để sử dụng tệp văn bản hoặc cơ sở dữ liệu nhúng cho tôi hiện đang sử dụng Redis. ví dụ: Để có được nhật ký lỗi cuộn kết hợp thời gian thực cho tất cả các dịch vụ của chúng tôi (vốn nổi tiếng là một nhiệm vụ khó khăn đối với chúng tôi), giờ đây chỉ được thực hiện với một vài dòng bằng cách chỉ chờ xử lý lỗi cho danh sách phía máy chủ Redis và sau đó cắt xén danh sách để chỉ giữ 1000 cuối cùng, ví dụ:

var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);

Tôi không có kinh nghiệm trực tiếp. Nhưng tôi thấy mục blog này khá thú vị.

Tôi thấy nỗ lực ánh xạ các đối tượng miền phần mềm (ví dụ aSalesOrder, aCustomer ...) sang cơ sở dữ liệu quan hệ hai chiều (hàng và cột) cần rất nhiều mã để lưu / cập nhật và sau đó một lần nữa để khởi tạo một thể hiện đối tượng miền từ nhiều bảng . Chưa kể hiệu năng đạt được khi có tất cả các phép nối đó, tất cả các đĩa đó đều đọc ... chỉ để xem / thao tác với một đối tượng miền như đơn đặt hàng hoặc hồ sơ khách hàng.

Chúng tôi đã chuyển sang Hệ thống quản lý cơ sở dữ liệu đối tượng (ODBMS). Chúng nằm ngoài khả năng của các hệ thống noQuery được liệt kê. GemStone / S (cho Smalltalk) là một ví dụ như vậy. Có các giải pháp ODBMS khác có trình điều khiển cho nhiều ngôn ngữ. Một lợi ích nhà phát triển chính, hệ thống phân cấp lớp của bạn sẽ tự động là lược đồ cơ sở dữ liệu, các lớp con và tất cả. Chỉ cần sử dụng ngôn ngữ hướng đối tượng của bạn để làm cho các đối tượng liên tục đến cơ sở dữ liệu. Các hệ thống ODBMS cung cấp tính toàn vẹn giao dịch cấp ACID, do đó, nó cũng sẽ hoạt động trong các hệ thống tài chính.

Tôi đã chuyển từ MySQL (InnoDB) sang cassandra cho hệ thống M2M, về cơ bản lưu trữ các chuỗi cảm biến theo thời gian cho từng thiết bị. Mỗi dữ liệu được lập chỉ mục bởi (device_id, date) và (device_id, type_of_sensor, date). Phiên bản MySQL chứa 20 triệu hàng.

MySQL:

• Thiết lập đồng bộ chủ-chủ. Rất ít vấn đề xuất hiện xung quanh việc mất đồng bộ hóa . Đó là căng thẳng và đặc biệt là trong thời gian đầu có thể mất nhiều giờ để khắc phục.
• Thời gian chèn không phải là vấn đề nhưng truy vấn cần nhiều bộ nhớ hơn khi dữ liệu tăng lên. Vấn đề là các chỉ số được coi là một tổng thể. Trong trường hợp của tôi, tôi chỉ sử dụng một phần rất mỏng của các chỉ mục cần thiết để tải vào bộ nhớ (chỉ vài phần trăm thiết bị được theo dõi thường xuyên và đó là dữ liệu gần đây nhất).
• Thật khó để sao lưu . Rsync không thể thực hiện sao lưu nhanh trên các tệp bảng InnoDB lớn.
• Rõ ràng là không thể cập nhật lược đồ bảng nặng , vì nó chiếm quá nhiều thời gian (giờ).
• Việc nhập dữ liệu mất nhiều giờ (ngay cả khi việc lập chỉ mục được thực hiện cuối cùng). Kế hoạch giải cứu tốt nhất là luôn giữ một vài bản sao của cơ sở dữ liệu (tệp dữ liệu + nhật ký).
• Chuyển từ một công ty lưu trữ sang một công ty khác thực sự là một vấn đề lớn . Nhân rộng phải được xử lý rất cẩn thận.

Cassandra:

• Thậm chí dễ cài đặt hơn MySQL.
• Yêu cầu rất nhiều RAM. Một phiên bản 2 GB không thể làm cho nó chạy trong các phiên bản đầu tiên, bây giờ nó có thể hoạt động với phiên bản 1 GB nhưng đó không phải là ý tưởng (cách quá nhiều dữ liệu tuôn ra). Cho nó 8GB là đủ trong trường hợp của chúng tôi.
• Khi bạn hiểu cách bạn sắp xếp dữ liệu của mình, việc lưu trữ rất dễ dàng. Yêu cầu phức tạp hơn một chút. Nhưng một khi bạn vượt qua nó, nó sẽ rất nhanh (bạn thực sự không thể mắc lỗi trừ khi bạn thực sự muốn).
• Nếu bước trước đó được thực hiện đúng, nó vẫn và siêu nhanh.
• Dường như dữ liệu được tổ chức để sao lưu. Mỗi dữ liệu mới được thêm vào dưới dạng tệp mới. Cá nhân tôi, nhưng đó không phải là một điều tốt, xả dữ liệu mỗi đêm và trước mỗi lần tắt máy (thường là để nâng cấp) để việc khôi phục mất ít thời gian hơn, vì chúng tôi có ít nhật ký để đọc. Nó không tạo ra nhiều tập tin được nén.
• Nhập dữ liệu nhanh như địa ngục. Và càng nhiều máy chủ bạn có càng nhanh. Xuất và nhập hàng gigabyte dữ liệu không còn là vấn đề nữa.
• Không có một lược đồ là một điều rất thú vị bởi vì bạn có thể làm cho dữ liệu của bạn phát triển để làm theo nhu cầu của bạn. Điều này có thể có nghĩa là có các phiên bản khác nhau của dữ liệu của bạn cùng một lúc trên cùng một họ cột.
• Thêm một máy chủ là dễ dàng (mặc dù không nhanh) nhưng tôi đã không thực hiện nó trên một thiết lập đa trung tâm dữ liệu.

Lưu ý: Tôi cũng đã sử dụng elaticsearch (tài liệu được định hướng dựa trên lucene) và tôi nghĩ rằng nó nên được coi là cơ sở dữ liệu NoQuery. Nó được phân phối, đáng tin cậy và thường nhanh (một số truy vấn phức tạp có thể thực hiện khá tệ).

Tôi không. Tôi muốn sử dụng một kho lưu trữ khóa-giá trị đơn giản và miễn phí mà tôi có thể gọi trong quá trình nhưng điều đó không tồn tại trên nền tảng Windows. Bây giờ tôi sử dụng Sqlite nhưng tôi muốn sử dụng một cái gì đó như Nội các Tokyo. BerkeleyDB có "vấn đề" giấy phép.

Tuy nhiên, nếu bạn muốn sử dụng HĐH Windows, sự lựa chọn cơ sở dữ liệu NoQuery của bạn bị hạn chế. Và không phải lúc nào cũng là nhà cung cấp C #

Tôi đã thử MongoDB và nó nhanh hơn 40 lần so với Sqlite, vì vậy có lẽ tôi nên sử dụng nó. Nhưng tôi vẫn hy vọng cho một giải pháp đơn giản trong quá trình.

Tôi đã sử dụng redis để lưu trữ thông điệp đăng nhập trên các máy. Nó rất dễ thực hiện, và rất hữu ích. Redis thực sự đá

Chúng tôi đã thay thế cơ sở dữ liệu postgres bằng cơ sở dữ liệu tài liệu CouchDB vì không có lược đồ cố định là một lợi thế mạnh đối với chúng tôi. Mỗi tài liệu có số lượng chỉ mục khác nhau được sử dụng để truy cập tài liệu đó.

Tôi đã sử dụng Couchbase trong quá khứ và chúng tôi đã gặp phải các vấn đề tái cân bằng và hàng loạt vấn đề khác. Hiện tại tôi đang sử dụng Redis trong một số dự án sản xuất. Tôi đang sử dụng redislabs.com , một dịch vụ được quản lý dành cho Redis, đảm nhiệm việc nhân rộng các cụm Redis của bạn. Tôi đã xuất bản một video về sự kiên trì của đối tượng trên blog của mình tại http://thomasjaeger.wordpress.com cho thấy cách sử dụng Redis trong mô hình nhà cung cấp và cách lưu trữ các đối tượng C # của bạn vào Redis. Hãy xem.

Tôi sẽ khuyến khích bất cứ ai đọc cái này để thử Couchbase một lần nữa khi 3.0 đã ra khỏi cửa. Có hơn 200 tính năng mới cho người mới bắt đầu. Hiệu suất, tính khả dụng, khả năng mở rộng và các tính năng quản lý dễ dàng của Couchbase Server tạo nên một cơ sở dữ liệu cực kỳ linh hoạt, khả dụng cao. UI quản lý được tích hợp sẵn và các API tự động khám phá các nút cụm, do đó không cần phải có bộ cân bằng tải từ ứng dụng đến DB. Mặc dù chúng tôi không có dịch vụ được quản lý tại thời điểm này, bạn có thể chạy couchbase trên những thứ như AWS, RedHat Gears, Cloudera, Rackspace, Docker Container như CloudSoft, và nhiều hơn nữa. Về việc tái cân bằng, nó phụ thuộc vào những gì bạn đề cập cụ thể nhưng Couchbase không tự động cân bằng lại sau khi lỗi nút, như được thiết kế, nhưng quản trị viên có thể thiết lập chuyển đổi dự phòng tự động cho lỗi nút đầu tiên và sử dụng API của chúng tôi, bạn cũng có thể có quyền truy cập vào vbuckets bản sao để đọc trước khi kích hoạt chúng hoặc sử dụng RestAPI mà bạn có thể thực thi chuyển đổi dự phòng bằng công cụ giám sát. Đây là một trường hợp đặc biệt nhưng có thể được thực hiện.

Chúng tôi có xu hướng không cân bằng lại ở bất kỳ chế độ nào trừ khi nút hoàn toàn ngoại tuyến và không bao giờ quay lại hoặc một nút mới đã sẵn sàng để được cân bằng tự động. Dưới đây là một vài hướng dẫn để giúp bất kỳ ai quan tâm đến việc xem một trong những cơ sở dữ liệu NoQuery có hiệu suất cao nhất là gì.

1. Máy chủ Couchbase 3.0
2. Hướng dẫn quản trị
3. API REST
4. Hướng dẫn dành cho nhà phát triển

Cuối cùng, tôi cũng khuyến khích bạn kiểm tra N1QL để truy vấn phân tán:

1. Hướng dẫn N1QL
2. Hướng dẫn N1QL

Cảm ơn đã đọc và cho tôi hoặc người khác biết nếu bạn cần thêm trợ giúp!

Austin

Tôi đã sử dụng Vertica trong quá khứ. Nó phụ thuộc vào việc nén cột & tiến hành đọc đĩa và giảm nhu cầu lưu trữ để tận dụng tối đa phần cứng của bạn. Tải dữ liệu nhanh hơn và đồng thời cao hơn cho phép bạn cung cấp dữ liệu phân tích cho nhiều người dùng hơn với độ trễ tối thiểu.

Trước đó, chúng tôi đã truy vấn cơ sở dữ liệu của Oracle có hàng tỷ hồ sơ và hiệu suất rất tối ưu. Các truy vấn mất 8 đến 12 giây để chạy, ngay cả sau khi tối ưu hóa với SSD. Do đó, chúng tôi cảm thấy cần phải sử dụng cơ sở dữ liệu định hướng phân tích, được tối ưu hóa đọc nhanh hơn. Với cụm Vertica đằng sau lớp dịch vụ tinh gọn, chúng tôi có thể chạy API với hiệu suất dưới giây.

Vertica lưu trữ dữ liệu trong các phép chiếu theo định dạng tối ưu hóa việc thực hiện truy vấn. Tương tự như các khung nhìn cụ thể hóa, các bộ kết quả dự trữ lưu trữ trên đĩa HOẶC SSD thay vì tính toán chúng mỗi khi chúng được sử dụng trong một truy vấn. Các phép chiếu cung cấp các lợi ích sau:

1. Nén và mã hóa dữ liệu để giảm không gian lưu trữ.
2. Đơn giản hóa phân phối trên toàn bộ cơ sở dữ liệu.
3. Cung cấp sẵn sàng cao và phục hồi.

Vertica tối ưu hóa cơ sở dữ liệu bằng cách phân phối dữ liệu trên toàn cụm bằng cách sử dụng Phân đoạn.

1. Phân đoạn đặt một phần dữ liệu trên một nút.
2. Nó phân phối đều dữ liệu trên tất cả các nút. Do đó, mỗi nút thực hiện một phần của quá trình truy vấn.
3. Truy vấn chạy trên cụm và mọi nút nhận kế hoạch truy vấn.
4. Kết quả của các truy vấn được tổng hợp và sử dụng để tạo đầu ra.

Để biết thêm, vui lòng tham khảo tài liệu của Vertica @ https://www.vertica.com/ledgeledridease/