#3 Citus Data - Phải chăng bạn có nên sử dụng nó hay không?
Lại tiếp tục với Citus Data và cơ sở dữ liệu phân tán, như bài viết trước thì có lẽ các bạn đã mường tượng ra được cái Citus data là...
Lại tiếp tục với Citus Data và cơ sở dữ liệu phân tán, như bài viết trước thì có lẽ các bạn đã mường tượng ra được cái Citus data là gì rồi nhỉ, nếu chưa thì bạn có thể đọc lại tại
#1 Citus data (cơ sở dữ liệu phân tán) và câu chuyện tăng hiệu năng
Nếu bạn đang tìm kiếm giải pháp để có thể scale out (mở rộng) các thành phần thuê dịch vụ (multi-tenant) hay bạn muốn xây dựng một bảng điều khiển phân tích thời gian thực, thứ mà giúp cho khách hàng của bạn có thể truy vấn và phân tích với tốc độ hiệu năng rất cao, hàng tỉ rows (hàng) dữ liệu. Điều đáng đề cập ở đây là scale out theo chiều ngang (horizontally) thay vì theo chiều dọc (vertically) như truyền thống. Đọc cái mở đầu đã chẳng hiểu gì rồi! Cùng đi từng định nghĩa một nhé. Mình sẽ lấy theo ví dụ giúp bạn tưởng tượng hình dung dễ dàng hơn. Đầu tiên là siêu mở rộng (Hyperscale), vấn đề mở rộng cơ sở dữ liệu cũng như hạ tầng trong phát triển phần mềm dường như là khá quan trọng. Chẳng ai muốn viết một phần mềm mà nó chỉ đáp ứng được nhu cầu hiện tại trong khi công nghệ nhu cầu mỗi lúc một tăng. Điều mở rộng và khả năng tương thích để mở rộng là điều cần thiết trong phát triển phần mềm. Nhưng thứ mà bạn xây dựng và phát triển cách đây 10 năm, 20 năm làm sao bạn biết được nhu cầu tương lai như thế nào để có thể chuẩn bị sẵn sàng cho mở rộng. Điều bạn quan tâm ở đây chỉ là làm sao để tương thích với mở rộng đó dễ dàng và tốn ít chi phí nhất có thể. Ví dụ, bạn mới xây dựng một trang web với sức chứa của cơ sở dữ liệu lưu đủ 1 triệu người dùng, điều gì sẽ xảy ra khi website của bạn quá hot và nó lên đến cả tỉ người dùng vào sau thời điểm phát hành 1 tuần sau đó. Tất nhiên là bạn nâng cơ sở hạ tầng từ 1GB dung lượng lên 10GB dung lượng rồi. Nhưng mà đời đâu như là mơ, khi chỉ nâng dung lượng như thế, khi bạn truy vấn lấy dữ liệu của một người dùng, bạn phải tìm kiếm trong 1 tỉ người dùng khác để có thể tìm thấy dữ liệu của bạn. Cái thời gian truy vấn đó bạn hình dung sẽ mất bao lâu đây? Chưa kể Ram, CPU xử lý cho hàng tỉ người dùng đó sẽ tăng theo, thập chí sập luôn cả hệ thống. Bạn có muốn vì những người dùng mới mà làm ảnh hưởng đến tập người dùng cũ đang hái ra tiền ở thời điểm hiện tại không? Việc mở rộng phải nhanh, đáp ứng tốt, vận hành, cấu hình, quản lý dễ dàng. Khi đó thuật ngữ siêu mở rộng Hyperscale ra đời. Tiếp đó là thuật ngữ worry-free và worry-free Postgres. Mình cũng không biết dịch từ worry-free ra tiếng việt là gì nữa, sự thảnh thơi chăng@@ Hay như câu sologan của Postgres (một cơ sở dữ liệu quan hệ dối tượng) Never Worry About Scaling Your Database Again. Đúng là hay thật, bạn sẽ không bao giờ lo lắng về vấn đề mở rộng cơ sở dữ liệu một lần nào nữa. Có lẽ từ worry-free xuất phát từ đây, giúp hệ thống thảnh thơi nhàn hạ, dễ dàng mở rộng, dễ dàng vận hành. Một thuật ngữ mà gắn liền với sự mở rộng hệ thống đó là Cluster. Clustering chính là 1 kiến trúc được tạo ra với mục đích đảm bảo nâng cao khả năng sẵn sàng cho những hệ thống mạng. Clustering bao gồm những server riêng lẻ được kết nối với nhau đồng thời hoạt động lại cùng nhau trong 1 hệ thống. Những server này giao tiếp với nhau với mục đích trao đổi thông tin và giao tiếp với cả những mạng bên ngoài để thực hiện những yêu cầu. Trong trường hợp có lỗi xảy ra những dịch vụ trong cluster hoạt động tương tác với nhau để duy trì tính ổn định và độ sẵn sàng cao cho hệ thống. Được rồi! Đi vào định nghĩa Citus, nó là một thứ dựa trên worry-free Postgres giúp bạn có thể mở rộng cơ sở dữ liệu. Nó là sự phát triển mở rộng của cơ sở dữ liệu phân tán trong Postgres, bên cạnh việc truy vấn trong một cluster của một máy. Citus chỉ hỗ trợ PostgreSQL tại thời điểm hiện tại, nên nếu hệ thống của bạn đang sử dụng hệ cơ sở dữ liệu quan hệ này thì có thể cân nhắc lợi ích của việc sử dụng citus. Lại khó hiểu rồi, vậy cơ sở dữ liệu phân tán là gì? Hiểu đơn giản là bạn lưu dữ liệu ở nhiều nơi, mỗi nơi một ít. Ví dụ, bạn có một bảng lưu thông tin người khách hàng gồm (mã khách hàng, họ, tên, màu sắc khách hàng đó yêu thích). Theo nguyên tắc một khối monolithic thì nó sẽ lưu hết tại một máy chủ chửa cả 4 thông tin trên. Khi bạn truy vấn lấy khách hàng mã thứ nhất thì cứ thế lấy ra thôi. Nhưng vấn đề là có 1 tỉ khách hàng ban đầu mình đề cập thì hệ thống của bạn phải tìm kiếm hàng triệu dữ liệu của khách hàng khách trong cùng một bảng. Còn một vấn đề thứ hai là bạn chỉ muốn lấy thông tin của màu sắc khách hàng bạn yêu thích thôi. Bạn không quan tâm đến họ, tên khách hàng đó. Khi đó bài toán đặt ra là chia dữ liệu của bạn làm sao để tối ưu thời gian truy vấn lấy lên được. Có 2 cách chia: - Bạn chia theo mã khách hàng, từ mã 1 đến mã 100 thì lưu ở máy thứ nhất, từ 100 đến 200 chia ở máy thứ 2,... Mình nói máy cho dễ hiểu thôi nhưng thực tế là trên node, một máy có thể xây dựng nhiều cluster, một cluster có thể xây dựng nhiều node (server). Đến khi bạn muốn lấy dữ liệu mã thứ 5 bạn chỉ việc vào node 1 truy vấn thôi. Dễ hiểu đúng không! Đây được gọi là chia cơ sở dữ liệu phân tán theo chiều ngang. - Bạn để trường họ, tên ở máy thứ nhất hoặc node thứ nhất, bạn để trường màu sắc yêu thích ở máy thứ hai. Khi bạn chỉ muốn lấy dữ liệu màu sắc yêu thích của khách hàng thì bạn chỉ vào máy thứ 2 bạn lấy mà thôi. Đây được gọi là chia cơ sở dữ liệu phân tán theo chiều dọc Quay trở lại vấn đề Citus, thì Citus là dạng mở rộng cơ sở dữ liệu phân tán của cơ sở dữ liệu quan hệ PostgreSQL theo chiều ngang. Bên cạnh đó nó thực thi truy vấn song song (bất đồng bộ) một cách mà họ coi là real-time (ngay lập tức) chỉ mất nhỏ hơn một giây đối với dữ liệu lớn. Có 3 điều mà Citus luôn sẵn sàng đáp ứng đó là:- Nó là mã nguồn mở và được nằm ngay trong Postgres server- Nó có hỗ trợ công cụ quản lý bảo mật (security) và quản lý cluster.- Nó sẵn sàng build trên cloud (đám mây) của Azure và AWS (tuy rằng AWS không còn hỗ trợ những người dùng mới nữa) Tiếp theo là Citus sử dụng 2 kỹ thuật sharding và replication. - Sharding là một mẫu kiến trúc cơ sở dữ liệu liên quan tới chia cắt theo chiều ngang. Nó chia bảng gốc thành nhiều bảng khác nhau, mỗi bảng sẽ giống nhau về schema(lược đồ) và columns(tất cả các cột). Bên cạch đó, nó còn có một cột nhắm liên kết và tìm kiếm dữ liệu liên quan, chẳng hạn như mã khách hàng ở ví dụ bên trên. Điều quan trọng là cột liên kết này phải là duy nhất và không được thay đổi. - Replication là một bộ các giải pháp cho phép sao chép và phân phối cơ sở dữ liệu giữa các server và đồng bộ chúng nhằm duy trì tính nhất quán dữ liệu. Nó là giải pháp được ứng dụng cho môi trường phân phối dữ liệu trên nhiều server Bài viết sau mình sẽ đi tiếp vào việc tại sao và khi nào thì nên dùng Citus. Cám ơn các bạn đã theo dõi!blog.ntechdevelopers.com
Nếu bạn đang tìm kiếm giải pháp để có thể scale out (mở rộng) các thành phần thuê dịch vụ (multi-tenant) hay bạn muốn xây dựng một bảng điều khiển phân tích thời gian thực, thứ mà giúp cho khách hàng của bạn có thể truy vấn và phân tích với tốc độ hiệu năng rất cao, hàng tỉ rows (hàng) dữ liệu. Điều đáng đề cập ở đây là scale out theo chiều ngang (horizontally) thay vì theo chiều dọc (vertically) như truyền thống. Đọc cái mở đầu đã chẳng hiểu gì rồi! Cùng đi từng định nghĩa một nhé. Mình sẽ lấy theo ví dụ giúp bạn tưởng tượng hình dung dễ dàng hơn. Đầu tiên là siêu mở rộng (Hyperscale), vấn đề mở rộng cơ sở dữ liệu cũng như hạ tầng trong phát triển phần mềm dường như là khá quan trọng. Chẳng ai muốn viết một phần mềm mà nó chỉ đáp ứng được nhu cầu hiện tại trong khi công nghệ nhu cầu mỗi lúc một tăng. Điều mở rộng và khả năng tương thích để mở rộng là điều cần thiết trong phát triển phần mềm. Nhưng thứ mà bạn xây dựng và phát triển cách đây 10 năm, 20 năm làm sao bạn biết được nhu cầu tương lai như thế nào để có thể chuẩn bị sẵn sàng cho mở rộng. Điều bạn quan tâm ở đây chỉ là làm sao để tương thích với mở rộng đó dễ dàng và tốn ít chi phí nhất có thể. Ví dụ, bạn mới xây dựng một trang web với sức chứa của cơ sở dữ liệu lưu đủ 1 triệu người dùng, điều gì sẽ xảy ra khi website của bạn quá hot và nó lên đến cả tỉ người dùng vào sau thời điểm phát hành 1 tuần sau đó. Tất nhiên là bạn nâng cơ sở hạ tầng từ 1GB dung lượng lên 10GB dung lượng rồi. Nhưng mà đời đâu như là mơ, khi chỉ nâng dung lượng như thế, khi bạn truy vấn lấy dữ liệu của một người dùng, bạn phải tìm kiếm trong 1 tỉ người dùng khác để có thể tìm thấy dữ liệu của bạn. Cái thời gian truy vấn đó bạn hình dung sẽ mất bao lâu đây? Chưa kể Ram, CPU xử lý cho hàng tỉ người dùng đó sẽ tăng theo, thập chí sập luôn cả hệ thống. Bạn có muốn vì những người dùng mới mà làm ảnh hưởng đến tập người dùng cũ đang hái ra tiền ở thời điểm hiện tại không? Việc mở rộng phải nhanh, đáp ứng tốt, vận hành, cấu hình, quản lý dễ dàng. Khi đó thuật ngữ siêu mở rộng Hyperscale ra đời. Tiếp đó là thuật ngữ worry-free và worry-free Postgres. Mình cũng không biết dịch từ worry-free ra tiếng việt là gì nữa, sự thảnh thơi chăng@@ Hay như câu sologan của Postgres (một cơ sở dữ liệu quan hệ dối tượng) Never Worry About Scaling Your Database Again. Đúng là hay thật, bạn sẽ không bao giờ lo lắng về vấn đề mở rộng cơ sở dữ liệu một lần nào nữa. Có lẽ từ worry-free xuất phát từ đây, giúp hệ thống thảnh thơi nhàn hạ, dễ dàng mở rộng, dễ dàng vận hành. Một thuật ngữ mà gắn liền với sự mở rộng hệ thống đó là Cluster. Clustering chính là 1 kiến trúc được tạo ra với mục đích đảm bảo nâng cao khả năng sẵn sàng cho những hệ thống mạng. Clustering bao gồm những server riêng lẻ được kết nối với nhau đồng thời hoạt động lại cùng nhau trong 1 hệ thống. Những server này giao tiếp với nhau với mục đích trao đổi thông tin và giao tiếp với cả những mạng bên ngoài để thực hiện những yêu cầu. Trong trường hợp có lỗi xảy ra những dịch vụ trong cluster hoạt động tương tác với nhau để duy trì tính ổn định và độ sẵn sàng cao cho hệ thống. Được rồi! Đi vào định nghĩa Citus, nó là một thứ dựa trên worry-free Postgres giúp bạn có thể mở rộng cơ sở dữ liệu. Nó là sự phát triển mở rộng của cơ sở dữ liệu phân tán trong Postgres, bên cạnh việc truy vấn trong một cluster của một máy. Citus chỉ hỗ trợ PostgreSQL tại thời điểm hiện tại, nên nếu hệ thống của bạn đang sử dụng hệ cơ sở dữ liệu quan hệ này thì có thể cân nhắc lợi ích của việc sử dụng citus. Lại khó hiểu rồi, vậy cơ sở dữ liệu phân tán là gì? Hiểu đơn giản là bạn lưu dữ liệu ở nhiều nơi, mỗi nơi một ít. Ví dụ, bạn có một bảng lưu thông tin người khách hàng gồm (mã khách hàng, họ, tên, màu sắc khách hàng đó yêu thích). Theo nguyên tắc một khối monolithic thì nó sẽ lưu hết tại một máy chủ chửa cả 4 thông tin trên. Khi bạn truy vấn lấy khách hàng mã thứ nhất thì cứ thế lấy ra thôi. Nhưng vấn đề là có 1 tỉ khách hàng ban đầu mình đề cập thì hệ thống của bạn phải tìm kiếm hàng triệu dữ liệu của khách hàng khách trong cùng một bảng. Còn một vấn đề thứ hai là bạn chỉ muốn lấy thông tin của màu sắc khách hàng bạn yêu thích thôi. Bạn không quan tâm đến họ, tên khách hàng đó. Khi đó bài toán đặt ra là chia dữ liệu của bạn làm sao để tối ưu thời gian truy vấn lấy lên được. Có 2 cách chia: - Bạn chia theo mã khách hàng, từ mã 1 đến mã 100 thì lưu ở máy thứ nhất, từ 100 đến 200 chia ở máy thứ 2,... Mình nói máy cho dễ hiểu thôi nhưng thực tế là trên node, một máy có thể xây dựng nhiều cluster, một cluster có thể xây dựng nhiều node (server). Đến khi bạn muốn lấy dữ liệu mã thứ 5 bạn chỉ việc vào node 1 truy vấn thôi. Dễ hiểu đúng không! Đây được gọi là chia cơ sở dữ liệu phân tán theo chiều ngang. - Bạn để trường họ, tên ở máy thứ nhất hoặc node thứ nhất, bạn để trường màu sắc yêu thích ở máy thứ hai. Khi bạn chỉ muốn lấy dữ liệu màu sắc yêu thích của khách hàng thì bạn chỉ vào máy thứ 2 bạn lấy mà thôi. Đây được gọi là chia cơ sở dữ liệu phân tán theo chiều dọc Quay trở lại vấn đề Citus, thì Citus là dạng mở rộng cơ sở dữ liệu phân tán của cơ sở dữ liệu quan hệ PostgreSQL theo chiều ngang. Bên cạnh đó nó thực thi truy vấn song song (bất đồng bộ) một cách mà họ coi là real-time (ngay lập tức) chỉ mất nhỏ hơn một giây đối với dữ liệu lớn. Có 3 điều mà Citus luôn sẵn sàng đáp ứng đó là:- Nó là mã nguồn mở và được nằm ngay trong Postgres server- Nó có hỗ trợ công cụ quản lý bảo mật (security) và quản lý cluster.- Nó sẵn sàng build trên cloud (đám mây) của Azure và AWS (tuy rằng AWS không còn hỗ trợ những người dùng mới nữa) Tiếp theo là Citus sử dụng 2 kỹ thuật sharding và replication. - Sharding là một mẫu kiến trúc cơ sở dữ liệu liên quan tới chia cắt theo chiều ngang. Nó chia bảng gốc thành nhiều bảng khác nhau, mỗi bảng sẽ giống nhau về schema(lược đồ) và columns(tất cả các cột). Bên cạch đó, nó còn có một cột nhắm liên kết và tìm kiếm dữ liệu liên quan, chẳng hạn như mã khách hàng ở ví dụ bên trên. Điều quan trọng là cột liên kết này phải là duy nhất và không được thay đổi. - Replication là một bộ các giải pháp cho phép sao chép và phân phối cơ sở dữ liệu giữa các server và đồng bộ chúng nhằm duy trì tính nhất quán dữ liệu. Nó là giải pháp được ứng dụng cho môi trường phân phối dữ liệu trên nhiều server Bài viết sau mình sẽ đi tiếp vào việc tại sao và khi nào thì nên dùng Citus. Cám ơn các bạn đã theo dõi!blog.ntechdevelopers.com
Đến với bài viết này thì mình muốn cùng các bạn phân tích xem khi nào dùng đến nó nhé!
Quay về citus data thì những khách hàng của họ đã cho ta thấy phần nào được khi nào chúng ta nên sử dụng citus rồi. Hầu hết các ứng dụng B2B đã có khái niệm về người thuê (tenant), khách hàng hoặc tài khoản được tích hợp vào mô hình dữ liệu của họ. Trong mô hình này, cơ sở dữ liệu phục vụ nhiều tenant, mỗi người trong số họ có dữ liệu tách biệt với những người thuê khác. Về khái niệm multi-tenancy thì mình lấy spiderum ra làm ví dụ nhé tuy là nó chỉ gần giống thôi. Mỗi người viết nằm trong nhóm top-user (thành viên nổi bật) sẽ có một domain riêng. Khi bạn vào trang cá nhân của họ thì lập tức spiderum sẽ trỏ tới domain riêng đó. Trong domain đó, mỗi cá nhân người dùng nổi bật sẽ có thể customs trang túy ý của họ và có tập dữ liệu riêng của họ mà không hề chung đụng với bất cứ người dùng nổi bật khác. Bạn hình dung mỗi thành viên nổi bật đó sẽ là một tenant và hệ thống gồm nhiều tenant sẽ là một hệ thống multi-tenancy.
Citus cung cấp đầy đủ SQL coverage cho dù nó có workload khá cao. Nó cũng cho phép bạn mở rộng cơ sở dữ liệu quan hệ của bạn đến hơn 100k tenants và nó bổ sung nhiều tính năng mới hỗ trợ multi-tenancy. Ví dụ như citus hỗ trợ việc đóng gói tenants lại nhằm đạt được hiệu suất với số lượng tenants lớn, bên cạnh đó nó cũng tối ưu việc sử dụng những nguồn dữ liệu chung cho những tenants có dùng chung để đơn giản hóa trong quá trình quản lý.
Đối với vấn đề tăng khả năng đáp ứng cho phép bạn mở rộng dữ liệu của tenant trên nhiều máy, dễ dàng tăng cpu, ram hay bộ nhớ. Trong tương lai, việc chia sẻ những cơ sở dữ liệu giống nhau giữa nhiều tenants sẽ hiệu quả hơn đối với quản lý phần cứng cũng như đơn giản hóa cơ sở dữ liệu.
Một số ưu điểm của citus đối với hệ thống multi-tenancy:
- Truy vấn nhanh trên tất cả các tenants
- Chia sẻ logic trong cơ sở dữ liệu thay vì trong tầng ứng dụng
- Lưu trữ được nhiều dữ liệu hơn so với single node PostgreSQL
- Mở rộng cơ sở dữ liệu nhưng vẫn giữa nguyên được dữ liệu SQL gốc ban đầu.
- Tăng hiệu năng với CCUs cao
- Phân tích tập dữ liệu nhanh
- Dễ dàng mở rộng tập khách hàng mới thông qua đăng ký tenant
- Đóng gói resource để tái sử dụng cho những tập khách hàng nhỏ và lớn khác nhau.
Một điều nữa mà citus đáp ứng cho những nhà phát triển đó là Real-time Analytics (Xây dựng Bảng điều khiển phân tích thời gian thực). Có lẽ đây là một tính năng nổi tập và là ưu điểm hàng đầu mà các nhà phát triển hướng tới khi chọn citus đầu tiên. Vì cho dù có multi-tenancy thì các cơ sở dữ liệu khác cũng có thể làm được, nhưng nếu hướng đến big data và phân tích cơ sở dữ liệu thì có lẽ khách hàng sẽ nhắm tới PostgreSQL và Citus. Ở bài viết này mình chỉ tóm tắt một số nét chính của tính năng Real-time Analytics trong Citus thôi, còn chi tiết và demo mình sẽ đề cập trong bài viết khác nhé
Đầu tiên thì bạn hãy tưởng tượng bạn cần truy vấn với một lượng dữ liệu rất lớn từ cơ sở dữ liệu lên với hình thức realtime, tức là vài tích tắc hoặc một giây lại cần truy vấn dữ liệu lên. Với cơ sở dữ liệu thông thường thì thật sự khó đáp ứng vì hệ thống sẽ mất một khoảng thời gian xử lý lọc, sắp xếp, liên kết bảng dữ liệu để có thể đưa lên cho người dùng, mà nó lại xảy ra một cách realtime, lặp đi lặp lại thì bạn nghĩ hệ thống nào chịu cho nổi.
Còn một điểm đang ghi nhận nữa là vấn đề tiến trình sự kiện của citus, ví dụ bạn có một khối lượng bảng dữ liệu rất lớn với nhiều node trên nhiều trạm cơ sở dữ liệu khác nhau, khi có một dữ liệu thay đổi hoặc thêm mới, bạn nghĩ bạn sẽ phải cập nhập và thông báo cho các thành phần còn lại không.
Thật vậy citus có một cơ chế event (sự kiện) và rollup data (cuộn dữ liệu) giúp bạn phát tín hiện cũng như sắp xếp lại dữ liệu khi có thay đổi hoặc thêm mới trên toàn mạng lưới cơ sở dữ liệu một cách realtime luôn.
Bên cạnh việc truy vấn cập nhập dữ liệu một cách đồng thời với chia thành nhiều luồng xử lý, sẽ khiến cho tốc độ truy vấn cũng như ghi và nhận được tăng cao. Việc chia cơ sở dữ liệu theo chiều ngang và đánh index theo thuật toán B-tree cũng giúp cho tốc độ xử lý của citus đáng kinh ngạc. Đúng nghĩa là realtime. Và cái realtime này lại được hỗ trợ trên một dashboard (bảng điều kiển) giúp người dùng có thể phân tích dữ liệu một cách dễ dàng hơn.
Đầu tiên thì bạn thử hỏi xem ứng dụng có bạn có cần thiết áp dụng hệ cơ sở dữ liệu phân tán không, nó tối ưu thì tối ưu thật đó nhưng chi phí cũng như công sức bỏ ra để handle nó không phải là nhỏ, nếu bạn không có nhu cầu scale out (mở rộng) với nhiều node, nhiều worker thì tốt nhất chẳng nên đánh đổi làm gì. Vì thực tế để bảo trì và vận hành hệ cơ sở dữ liệu này rất phức tạp và cần phải có kiến thức không chỉ là Dev hay DBA (Database Administrator) mà còn phải mạnh cả DevOps (Develope + Operation) nữa.
Nếu bạn không có nhu cầu phân tích dữ liệu lớn, không có yêu cầu gì về vấn đề realtime analytics thì bạn phân tích dữ liệu offline là đủ, cũng chẳng cần thiết giết gà dùng dao mổ trâu làm gì. Vừa khó khăn trong vấn đề tiếp cận công nghệ mới, vừa chưa chắc đúng mà có khi còn phân tích dữ liệu sai luôn ý
Nếu ứng dụng của bạn không cần xử lý đồng thời quá nhiều (a large number of concurrent users) thì bạn cũng chẳng cần quan tâm citus là gì cho mệt. Vì thực sự implement và maintain citus rất cực khổ cho dev. Từ việc handle max_connection, pool_size, dead_lock, rồi linq để có thể truy vấn được dữ liệu khi phân tán như vậy lên tầng ứng dụng rất mất thời gian cũng như công sức. Đó còn chưa kể khi mình tự hanlde hết thì sẽ phát sinh nhiều rủi ro trong logic của bạn.
Nếu truy vấn dữ liệu của ban thu thập ETL trả về nhiều kết quả dữ liệu hơn thay vì chỉ tổng hợp và phân tích dữ liệu. Nói sơ qua về ETL (Extract Transform Load) thì nó là quá trình "How to" dữ liệu được đưa vào từ các nguồn dữ liệu vào kho dữ liệu. Extracts dữ liệu tức là đi thu gom dữ liệu từ nhiều nguồn khác nhau. Transforms dữ liệu tức là chuyển đổi dữ liệu từ mục đích này sang much đích khác nhằm có được dữ liệu nghiệp vụ và phân tích chúng.DW hoặc DWH (Data Warehouse) là kho lưu trữ trung tâm của dữ liệu tích hợp từ một hoặc nhiều nguồn khác nhau.
Nhìn hình trên bạn sẽ hiểu quá trình thu thập và phân tích dữ liệu diễn ra như thế nào. Vậy nên khi áp dụng citus thì quá trình thu thập ETL này sẽ gặp khó khăn một chút, do cơ sở dữ liệu phân tán mà. Nên bạn hãy cân nhắc!
Trên đây là một số phân tích sơ bộ về Citus Data - Cơ sở dữ liệu phân tán dựa trên PostgreSQL. Hi vọng có thể giúp bạn hiểu được tại sao và khi nào dùng chúng.
--
Bài viết tới mình sẽ đi kỹ hơn về cách xây dựng Citus Data với Net core. Hi vọng được ủng hộ.
#2 PostgreSQL liệu có như tuyên bố “Cơ sở dữ liệu mã nguồn mở tiên tiến nhất thế giới”
Bài viết trước mình có nói đến citus data và postgres, trước khi đi tiếp sâu hơn về citus có lẽ mình nên đi dạo qua sơ lược về cơ sở dữ liệu quan hệ đối tượng PostgreSQL này trước để các bạn hiểu được tại sao lại chọn nó nhé! Đầu tiên thì bạn thường thấy một số loại cơ sở dữ liệu quan hệ hay được sử dụng trong dự án, phải kể đến SQL Server, My SQL, SQLlite, và Postgresql. Thường thì chúng ta ít quan tâm đến chọn loại cơ sở dữ liệu nào cho dự án của mình, có thể là các anh SA chọn, hoặc có thể là khách hàng chọn và yêu cầu chúng ta phát triển nó. Thật buồn cười khi chúng ta cứ phát triển theo những yêu cầu đó mà chẳng biết là tại sao, đến lúc có issue thì lại quay ra trách, cũng kỳ. Vậy nên mình cũng thử tìm hiểu nó để có thể nắm được những điểm mạnh yếu của từng cơ sở dữ liệu trước khi sử dụng. Mặc dù trong dự án, một cơ sở dữ liệu đã được lựa chọn thì ngay bản thân mình cũng không có đủ quyền hạn để thay đổi. Nhưng chí ít thì cũng nên biết tại sao chứ nhỉ! Các cơ sở dữ liệu trên thì có rất nhiều trang cũng như document ngay chính trang chủ của cơ sở dữ liệu đó đã đề cập rất rõ đến cách sử dụng rồi nên mình cũng chỉ ghi chú lại những thứ mà mình xem như là quan trọng khi sử dụng Postgresql này. Điều đầu tiên thì My SQL, PostgreSQL và SQLlite đều là mã nguồn mở, ai mà chẳng thích đồ free chứ, nhưng nếu dùng mã nguồn mở thì bạn hãy chú ý đến cộng đồng phát triển nó nhé, đôi khi cộng đồng quá ít, issue chưa được phát hiện thì toang cả một dự án lại khổ @@. Nói thì nói vậy thôi chứ cả 3 cơ sở dữ liệu trên đều có một cộng đồng rất lớn rồi. Thứ hai là PostgreSQL là cơ sở dữ liệu quan hệ đối tượng trong khi MySQL chỉ là cơ sở dữ liệu đơn thuần. Chắc hẳn bạn cũng đã từng nghe qua lập trình hướng đối tượng và cũng từng nghe những thuộc tính của nó rồi. Đúng rồi đó, PostgreSQL cũng sở hữu tính năng kế thừa dành cho bảng (table inheritance) và overloading dành cho function. Điều này giúp ích rất nhiều khi thiết kế cơ sở dữ liệu. Thứ ba là PostgreSQL hỗ trợ mô hình ứng dụng với nhiều dạng như Json, Xml... trong khi MySQLchỉ hỗ trợ được Json mà thôi. Bên cạnh đó nó cũng hộ trợ nhiều ngôn ngữ thủ tục như pgSql, python, perf... Điều này giúp cho bản thân PostgreSQL có thể tương thích nhanh và dễ dàng mở rộng. Thứ nữa là các doanh nghiệp lớn vô cùng quan tâm ngoài khả năng mở rộng đó là khả năng quản lý số lượng người dùng đồng thời (CCUs) lên đến hàng terabyte và petabyte. PostgreSQL triển khai MVCC (Multiversion Concurrency Control) không làm ảnh hưởng đến việc hỗ trợ nhiều query đồng thời và nó cũng cho phép tạo partial index và bảo vệ tính bảo mật dữ liệu trong các cấp giao dịch khác nhau. Điền này dẫn đến ít rủi ro cho dữ liệu. Postgres phù hợp cho cả đọc và ghi dữ liệu. Tuy nhiên, lại tuy nhiên rồi, điều gì cũng có hạn chế của nó, đó là PostgreSQL có thiết lập số lượng max_connection trong khi MySQL thì không. Thông thương một hệ thống có RAM 16GB thường có thể thiết lập max_connection ~1000, trong mộ vài hệ thốn số lượng có thể lên đến 8k connection tuy nhiên những hệ thống này rất dễ gặp lỗi. Điều này là một điểm chú ý lớn khi sử dụng và thiết kế. Mình đã từng thấy một trường hợp thắt cổ chai ngay tầng database này rồi. Ví dụ chức năng login bạn có thể đưa vào cả triệu request nhưng connection database của bạn chỉ có 500 connection concurrency mà thôi. Khi đó bạn hiểu hệ thống của bạn sẽ xảy ra chuyện gì rồi đó, một con đường rộng thênh thang chứa được mấy chiếc ô tô tránh nhau nhưng khi vào nhà bạn lại qua một cái cổng chỉ có thể đi bộ được thôi. Thực sự bạn nên rất rất lưu ý về vấn đề này trong thiết kế cơ sở dữ liệu nhé! Bên cạnh vấn đề chịu tải và khả năng mở rộng đáng gờm của PostgreSQL thì các ông lớn thường chú ý đó là hiệu năng của nó, PostgreSQL có nhiều cơ chế index, khả năng join bảng, hỗ trợ thực thi câu query phức tạp, Triggers/Stored Procedures/Transactions cũng có khả năng tương thích rất cao. Điều này là một ưu điểm để mọi người có thể cân nhắc chọn PostgreSQL. Điều cuối cùng mình thất PostgreSQL khá hay ho là khả năng scale out, mở rộng vùng lưu trữ dữ liệu một cách tự động. Tuy rằng PostgreSQL không có bộ nhớ đệm như SQL Server nên không thể cache lại câu query trong quá trình truy vấn nhưng nó lại có một cơ chế khả dụng rất cao trong quá trình chạy runtime giúp các nhà phát triển xây dựng app, các nhà quản trị bảo vệ toàn vẹn dữ liệu, và tạo ra một môi trường chịu lỗi fault-tolerant giúp bạn quản lý dữ liệu bất kể tập dữ liệu lớn hay nhỏ. Fault tolerance đề cập đến khả năng của một hệ thống (computer, network, cloud cluster,) có khả năng tiếp tục hoạt động mà không bị gián đoạn khi một hoặc nhiều thành phần của nó gặp sự cố. Nhiều khi đi phỏng vấn, nhiều anh TA hỏi câu làm sao để ứng dụng của bạn không bao giờ chết, uhm thì... switch hệ thống dự phòng. Ở đây cũng vậy Fault tolerance ngăn chặn sự gián đoạn phát sinh từ một điểm thất bại duy nhất, đảm bảo tính sẵn sàng cao (high availability) và tính liên tục (business continuity) của các ứng dụng hoặc hệ thống thực hiện các nhiệm vụ quan trọng. Hình dung một chút: Một chiếc máy bay hai động cơ là một Fault-tolerant system: nếu động cơ này bị hỏng, động cơ kia sẽ hoạt động thay thế, điều này giúp máy bay vẫn tiếp tục hành trình bay của mình một cách trơn tru. Ngược lại, một chiếc xe với lốp dự phòng là highly available. Một chiếc lốp bị xẹp sẽ làm chiếc xe phải dừng lại, nhưng downtime sẽ là tối thiểu vì đã có lốp thay thế sẵn sàng, việc thay lốp xe sẽ diễn ra trong thời gian ít nhất. PostgreSQL hay ho thật đó nhưng không phải là không có nhược điểm đâu nhé! Tuy PostgreSQL có một cộng đồng hỗ trợ lớn nhưng mà làm việc với nó khá là thách thức, lượng công việc mình phải tự handle, xử lý để control khá nhiều như cache, tối ưu query, B-tree index, event... Những giải pháp cho những vấn đề ngoài luồng như vậy thường đòi hỏi sự hiểu biết rất sâu. Với mình thì nó cũng chỉ là cưỡi ngựa xem hoa mà thôi. Bạn có thể tìm hiểu tài liệu của nó tại https://www.postgresql.org/docs/ Ngoài một số những nhược điểm khác mình cũng đã đề cập ở trên như vấn đề giới hạn connection, vấn đề cache query thì một vấn đề cũng gây tốn tài nguyên bộ nhớ đó là nâng cấp version. Dù sao thì PostgreSQL cũng là mã nguồn mở, vấn đề upgrade version cũng là một vấn đề đáng lưu tâm. Tổng kết lại bằng một số bảng thống kê trên wiki giữa các cơ sở dữ liệu. Bài viết là những quan điểm và sự tìm hiểu cá nhân của bản thân mình, có thể còn nhiều thiếu sót, mong các bạn ủng hộ góp ý thêm.blog.ntechdevelopers.com
Bài viết trước mình có nói đến citus data và postgres, trước khi đi tiếp sâu hơn về citus có lẽ mình nên đi dạo qua sơ lược về cơ sở dữ liệu quan hệ đối tượng PostgreSQL này trước để các bạn hiểu được tại sao lại chọn nó nhé! Đầu tiên thì bạn thường thấy một số loại cơ sở dữ liệu quan hệ hay được sử dụng trong dự án, phải kể đến SQL Server, My SQL, SQLlite, và Postgresql. Thường thì chúng ta ít quan tâm đến chọn loại cơ sở dữ liệu nào cho dự án của mình, có thể là các anh SA chọn, hoặc có thể là khách hàng chọn và yêu cầu chúng ta phát triển nó. Thật buồn cười khi chúng ta cứ phát triển theo những yêu cầu đó mà chẳng biết là tại sao, đến lúc có issue thì lại quay ra trách, cũng kỳ. Vậy nên mình cũng thử tìm hiểu nó để có thể nắm được những điểm mạnh yếu của từng cơ sở dữ liệu trước khi sử dụng. Mặc dù trong dự án, một cơ sở dữ liệu đã được lựa chọn thì ngay bản thân mình cũng không có đủ quyền hạn để thay đổi. Nhưng chí ít thì cũng nên biết tại sao chứ nhỉ! Các cơ sở dữ liệu trên thì có rất nhiều trang cũng như document ngay chính trang chủ của cơ sở dữ liệu đó đã đề cập rất rõ đến cách sử dụng rồi nên mình cũng chỉ ghi chú lại những thứ mà mình xem như là quan trọng khi sử dụng Postgresql này. Điều đầu tiên thì My SQL, PostgreSQL và SQLlite đều là mã nguồn mở, ai mà chẳng thích đồ free chứ, nhưng nếu dùng mã nguồn mở thì bạn hãy chú ý đến cộng đồng phát triển nó nhé, đôi khi cộng đồng quá ít, issue chưa được phát hiện thì toang cả một dự án lại khổ @@. Nói thì nói vậy thôi chứ cả 3 cơ sở dữ liệu trên đều có một cộng đồng rất lớn rồi. Thứ hai là PostgreSQL là cơ sở dữ liệu quan hệ đối tượng trong khi MySQL chỉ là cơ sở dữ liệu đơn thuần. Chắc hẳn bạn cũng đã từng nghe qua lập trình hướng đối tượng và cũng từng nghe những thuộc tính của nó rồi. Đúng rồi đó, PostgreSQL cũng sở hữu tính năng kế thừa dành cho bảng (table inheritance) và overloading dành cho function. Điều này giúp ích rất nhiều khi thiết kế cơ sở dữ liệu. Thứ ba là PostgreSQL hỗ trợ mô hình ứng dụng với nhiều dạng như Json, Xml... trong khi MySQLchỉ hỗ trợ được Json mà thôi. Bên cạnh đó nó cũng hộ trợ nhiều ngôn ngữ thủ tục như pgSql, python, perf... Điều này giúp cho bản thân PostgreSQL có thể tương thích nhanh và dễ dàng mở rộng. Thứ nữa là các doanh nghiệp lớn vô cùng quan tâm ngoài khả năng mở rộng đó là khả năng quản lý số lượng người dùng đồng thời (CCUs) lên đến hàng terabyte và petabyte. PostgreSQL triển khai MVCC (Multiversion Concurrency Control) không làm ảnh hưởng đến việc hỗ trợ nhiều query đồng thời và nó cũng cho phép tạo partial index và bảo vệ tính bảo mật dữ liệu trong các cấp giao dịch khác nhau. Điền này dẫn đến ít rủi ro cho dữ liệu. Postgres phù hợp cho cả đọc và ghi dữ liệu. Tuy nhiên, lại tuy nhiên rồi, điều gì cũng có hạn chế của nó, đó là PostgreSQL có thiết lập số lượng max_connection trong khi MySQL thì không. Thông thương một hệ thống có RAM 16GB thường có thể thiết lập max_connection ~1000, trong mộ vài hệ thốn số lượng có thể lên đến 8k connection tuy nhiên những hệ thống này rất dễ gặp lỗi. Điều này là một điểm chú ý lớn khi sử dụng và thiết kế. Mình đã từng thấy một trường hợp thắt cổ chai ngay tầng database này rồi. Ví dụ chức năng login bạn có thể đưa vào cả triệu request nhưng connection database của bạn chỉ có 500 connection concurrency mà thôi. Khi đó bạn hiểu hệ thống của bạn sẽ xảy ra chuyện gì rồi đó, một con đường rộng thênh thang chứa được mấy chiếc ô tô tránh nhau nhưng khi vào nhà bạn lại qua một cái cổng chỉ có thể đi bộ được thôi. Thực sự bạn nên rất rất lưu ý về vấn đề này trong thiết kế cơ sở dữ liệu nhé! Bên cạnh vấn đề chịu tải và khả năng mở rộng đáng gờm của PostgreSQL thì các ông lớn thường chú ý đó là hiệu năng của nó, PostgreSQL có nhiều cơ chế index, khả năng join bảng, hỗ trợ thực thi câu query phức tạp, Triggers/Stored Procedures/Transactions cũng có khả năng tương thích rất cao. Điều này là một ưu điểm để mọi người có thể cân nhắc chọn PostgreSQL. Điều cuối cùng mình thất PostgreSQL khá hay ho là khả năng scale out, mở rộng vùng lưu trữ dữ liệu một cách tự động. Tuy rằng PostgreSQL không có bộ nhớ đệm như SQL Server nên không thể cache lại câu query trong quá trình truy vấn nhưng nó lại có một cơ chế khả dụng rất cao trong quá trình chạy runtime giúp các nhà phát triển xây dựng app, các nhà quản trị bảo vệ toàn vẹn dữ liệu, và tạo ra một môi trường chịu lỗi fault-tolerant giúp bạn quản lý dữ liệu bất kể tập dữ liệu lớn hay nhỏ. Fault tolerance đề cập đến khả năng của một hệ thống (computer, network, cloud cluster,) có khả năng tiếp tục hoạt động mà không bị gián đoạn khi một hoặc nhiều thành phần của nó gặp sự cố. Nhiều khi đi phỏng vấn, nhiều anh TA hỏi câu làm sao để ứng dụng của bạn không bao giờ chết, uhm thì... switch hệ thống dự phòng. Ở đây cũng vậy Fault tolerance ngăn chặn sự gián đoạn phát sinh từ một điểm thất bại duy nhất, đảm bảo tính sẵn sàng cao (high availability) và tính liên tục (business continuity) của các ứng dụng hoặc hệ thống thực hiện các nhiệm vụ quan trọng. Hình dung một chút: Một chiếc máy bay hai động cơ là một Fault-tolerant system: nếu động cơ này bị hỏng, động cơ kia sẽ hoạt động thay thế, điều này giúp máy bay vẫn tiếp tục hành trình bay của mình một cách trơn tru. Ngược lại, một chiếc xe với lốp dự phòng là highly available. Một chiếc lốp bị xẹp sẽ làm chiếc xe phải dừng lại, nhưng downtime sẽ là tối thiểu vì đã có lốp thay thế sẵn sàng, việc thay lốp xe sẽ diễn ra trong thời gian ít nhất. PostgreSQL hay ho thật đó nhưng không phải là không có nhược điểm đâu nhé! Tuy PostgreSQL có một cộng đồng hỗ trợ lớn nhưng mà làm việc với nó khá là thách thức, lượng công việc mình phải tự handle, xử lý để control khá nhiều như cache, tối ưu query, B-tree index, event... Những giải pháp cho những vấn đề ngoài luồng như vậy thường đòi hỏi sự hiểu biết rất sâu. Với mình thì nó cũng chỉ là cưỡi ngựa xem hoa mà thôi. Bạn có thể tìm hiểu tài liệu của nó tại https://www.postgresql.org/docs/ Ngoài một số những nhược điểm khác mình cũng đã đề cập ở trên như vấn đề giới hạn connection, vấn đề cache query thì một vấn đề cũng gây tốn tài nguyên bộ nhớ đó là nâng cấp version. Dù sao thì PostgreSQL cũng là mã nguồn mở, vấn đề upgrade version cũng là một vấn đề đáng lưu tâm. Tổng kết lại bằng một số bảng thống kê trên wiki giữa các cơ sở dữ liệu. Bài viết là những quan điểm và sự tìm hiểu cá nhân của bản thân mình, có thể còn nhiều thiếu sót, mong các bạn ủng hộ góp ý thêm.blog.ntechdevelopers.com
#3 Citus Data – Phải chăng bạn có nên sử dụng nó hay không?
Lại tiếp tục với Citus Data và cơ sở dữ liệu phân tán, như bài viết trước thì có lẽ các bạn đã mường tượng ra được cái Citus data là gì rồi nhỉ, nếu chưa thì bạn có thể đọc lại tại# http://blog.ntechdevelopers.com/citus-data-va-cau-chuyen-tang-hieu-nang-phan-1/ Đến với bài viết này thì mình muốn cùng các bạn phân tích xem khi nào dùng đến nó nhé! Điều đầu tiên phải nói citus data dùng rất nhiều đối với các ông lớn như Algolia, Heap, Chartbeat, Pex, Mixrank. Đặc điểm chung cho những khách hàng của citus đều là có lượng CCUs rất lớn, và họ cần phân tích dữ liệu big data theo thời gian thực. Một điều nữa là tập khách hàng này của citus đa số sẽ là B2B (Business to Business). Có thể bạn chưa biết đến B2B thì mình xin lấy ví dụ ngắn gọn cho bạn hình dung như sau. Khách hàng trong mô hình B2B ở đây không phải là một cá nhân, mà là một công ty, doanh nghiệp, cửa hàng, do đó có thể giá trị của hợp đồng, đơn hàng thường rất lớn, không thể giao dịch ngay trên sàn thương mại điện tử hoặc kênh thương mại điện tử riêng mà buộc phải ký hợp đồng bên ngoài (trong trường hợp cần thiết). Ví dụ Lazada, Tiki, Adayroi, Shopee,.. ở thị trường Việt Nam. Còn thị trường nước ngoài thì có thể kể đến Amazon, Taobao, Alibaba, Ebay,.. Nói chung theo dân dã thì B2B chính cò trung gian đó mọi người. Quay về citus data thì những khách hàng của họ đã cho ta thấy phần nào được khi nào chúng ta nên sử dụng citus rồi. Hầu hết các ứng dụng B2B đã có khái niệm về người thuê (tenant), khách hàng hoặc tài khoản được tích hợp vào mô hình dữ liệu của họ. Trong mô hình này, cơ sở dữ liệu phục vụ nhiều tenant, mỗi người trong số họ có dữ liệu tách biệt với những người thuê khác. Về khái niệm multi-tenancy thì mình lấy spiderum ra làm ví dụ nhé tuy là nó chỉ gần giống thôi. Mỗi người viết nằm trong nhóm top-user (thành viên nổi bật) sẽ có một domain riêng. Khi bạn vào trang cá nhân của họ thì lập tức spiderum sẽ trỏ tới domain riêng đó. Trong domain đó, mỗi cá nhân người dùng nổi bật sẽ có thể customs trang túy ý của họ và có tập dữ liệu riêng của họ mà không hề chung đụng với bất cứ người dùng nổi bật khác. Bạn hình dung mỗi thành viên nổi bật đó sẽ là một tenant và hệ thống gồm nhiều tenant sẽ là một hệ thống multi-tenancy. Citus cung cấp đầy đủ SQL coverage cho dù nó có workload khá cao. Nó cũng cho phép bạn mở rộng cơ sở dữ liệu quan hệ của bạn đến hơn 100k tenants và nó bổ sung nhiều tính năng mới hỗ trợ multi-tenancy. Ví dụ như citus hỗ trợ việc đóng gói tenants lại nhằm đạt được hiệu suất với số lượng tenants lớn, bên cạnh đó nó cũng tối ưu việc sử dụng những nguồn dữ liệu chung cho những tenants có dùng chung để đơn giản hóa trong quá trình quản lý.Đối với vấn đề tăng khả năng đáp ứng cho phép bạn mở rộng dữ liệu của tenant trên nhiều máy, dễ dàng tăng cpu, ram hay bộ nhớ. Trong tương lai, việc chia sẻ những cơ sở dữ liệu giống nhau giữa nhiều tenants sẽ hiệu quả hơn đối với quản lý phần cứng cũng như đơn giản hóa cơ sở dữ liệu. Một số ưu điểm của citus đối với hệ thống multi-tenancy:- Truy vấn nhanh trên tất cả các tenants- Chia sẻ logic trong cơ sở dữ liệu thay vì trong tầng ứng dụng- Lưu trữ được nhiều dữ liệu hơn so với single node PostgreSQL- Mở rộng cơ sở dữ liệu nhưng vẫn giữa nguyên được dữ liệu SQL gốc ban đầu.- Tăng hiệu năng với CCUs cao- Phân tích tập dữ liệu nhanh- Dễ dàng mở rộng tập khách hàng mới thông qua đăng ký tenant- Đóng gói resource để tái sử dụng cho những tập khách hàng nhỏ và lớn khác nhau. Một điều nữa mà citus đáp ứng cho những nhà phát triển đó là Real-time Analytics (Xây dựng Bảng điều khiển phân tích thời gian thực). Có lẽ đây là một tính năng nổi tập và là ưu điểm hàng đầu mà các nhà phát triển hướng tới khi chọn citus đầu tiên. Vì cho dù có multi-tenancy thì các cơ sở dữ liệu khác cũng có thể làm được, nhưng nếu hướng đến big data và phân tích cơ sở dữ liệu thì có lẽ khách hàng sẽ nhắm tới PostgreSQL và Citus. Ở bài viết này mình chỉ tóm tắt một số nét chính của tính năng Real-time Analytics trong Citus thôi, còn chi tiết và demo mình sẽ đề cập trong bài viết khác nhé Đầu tiên thì bạn hãy tưởng tượng bạn cần truy vấn với một lượng dữ liệu rất lớn từ cơ sở dữ liệu lên với hình thức realtime, tức là vài tích tắc hoặc một giây lại cần truy vấn dữ liệu lên. Với cơ sở dữ liệu thông thường thì thật sự khó đáp ứng vì hệ thống sẽ mất một khoảng thời gian xử lý lọc, sắp xếp, liên kết bảng dữ liệu để có thể đưa lên cho người dùng, mà nó lại xảy ra một cách realtime, lặp đi lặp lại thì bạn nghĩ hệ thống nào chịu cho nổi. Còn một điểm đang ghi nhận nữa là vấn đề tiến trình sự kiện của citus, ví dụ bạn có một khối lượng bảng dữ liệu rất lớn với nhiều node trên nhiều trạm cơ sở dữ liệu khác nhau, khi có một dữ liệu thay đổi hoặc thêm mới, bạn nghĩ bạn sẽ phải cập nhập và thông báo cho các thành phần còn lại không.Thật vậy citus có một cơ chế event (sự kiện) và rollup data (cuộn dữ liệu) giúp bạn phát tín hiện cũng như sắp xếp lại dữ liệu khi có thay đổi hoặc thêm mới trên toàn mạng lưới cơ sở dữ liệu một cách realtime luôn. Bên cạnh việc truy vấn cập nhập dữ liệu một cách đồng thời với chia thành nhiều luồng xử lý, sẽ khiến cho tốc độ truy vấn cũng như ghi và nhận được tăng cao. Việc chia cơ sở dữ liệu theo chiều ngang và đánh index theo thuật toán B-tree cũng giúp cho tốc độ xử lý của citus đáng kinh ngạc. Đúng nghĩa là realtime. Và cái realtime này lại được hỗ trợ trên một dashboard (bảng điều kiển) giúp người dùng có thể phân tích dữ liệu một cách dễ dàng hơn. Có lợi thì cũng có hại, có ưu điểm thì ắt cũng có nhược điểm, dưới đây là một số nhượng điểm và những cân nhắc khi chọn citus vào dự án của mình. Đầu tiên thì bạn thử hỏi xem ứng dụng có bạn có cần thiết áp dụng hệ cơ sở dữ liệu phân tán không, nó tối ưu thì tối ưu thật đó nhưng chi phí cũng như công sức bỏ ra để handle nó không phải là nhỏ, nếu bạn không có nhu cầu scale out (mở rộng) với nhiều node, nhiều worker thì tốt nhất chẳng nên đánh đổi làm gì. Vì thực tế để bảo trì và vận hành hệ cơ sở dữ liệu này rất phức tạp và cần phải có kiến thức không chỉ là Dev hay DBA (Database Administrator) mà còn phải mạnh cả DevOps (Develope + Operation) nữa. Nếu bạn không có nhu cầu phân tích dữ liệu lớn, không có yêu cầu gì về vấn đề realtime analytics thì bạn phân tích dữ liệu offline là đủ, cũng chẳng cần thiết giết gà dùng dao mổ trâu làm gì. Vừa khó khăn trong vấn đề tiếp cận công nghệ mới, vừa chưa chắc đúng mà có khi còn phân tích dữ liệu sai luôn ý Nếu ứng dụng của bạn không cần xử lý đồng thời quá nhiều (a large number of concurrent users) thì bạn cũng chẳng cần quan tâm citus là gì cho mệt. Vì thực sự implement và maintain citus rất cực khổ cho dev. Từ việc handle max_connection, pool_size, dead_lock, rồi linq để có thể truy vấn được dữ liệu khi phân tán như vậy lên tầng ứng dụng rất mất thời gian cũng như công sức. Đó còn chưa kể khi mình tự hanlde hết thì sẽ phát sinh nhiều rủi ro trong logic của bạn. Nếu truy vấn dữ liệu của ban thu thập ETL trả về nhiều kết quả dữ liệu hơn thay vì chỉ tổng hợp và phân tích dữ liệu. Nói sơ qua về ETL (Extract Transform Load) thì nó là quá trình How to dữ liệu được đưa vào từ các nguồn dữ liệu vào kho dữ liệu. Extracts dữ liệu tức là đi thu gom dữ liệu từ nhiều nguồn khác nhau. Transforms dữ liệu tức là chuyển đổi dữ liệu từ mục đích này sang much đích khác nhằm có được dữ liệu nghiệp vụ và phân tích chúng.DW hoặc DWH (Data Warehouse) là kho lưu trữ trung tâm của dữ liệu tích hợp từ một hoặc nhiều nguồn khác nhau. Nhìn hình trên bạn sẽ hiểu quá trình thu thập và phân tích dữ liệu diễn ra như thế nào. Vậy nên khi áp dụng citus thì quá trình thu thập ETL này sẽ gặp khó khăn một chút, do cơ sở dữ liệu phân tán mà. Nên bạn hãy cân nhắc! Trên đây là một số phân tích sơ bộ về Citus Data - Cơ sở dữ liệu phân tán dựa trên PostgreSQL. Hi vọng có thể giúp bạn hiểu được tại sao và khi nào dùng chúng. Bài viết tới mình sẽ đi kỹ hơn về cách xây dựng Citus Data với Net core. Hi vọng được ủng hộ.blog.ntechdevelopers.com
Lại tiếp tục với Citus Data và cơ sở dữ liệu phân tán, như bài viết trước thì có lẽ các bạn đã mường tượng ra được cái Citus data là gì rồi nhỉ, nếu chưa thì bạn có thể đọc lại tại# http://blog.ntechdevelopers.com/citus-data-va-cau-chuyen-tang-hieu-nang-phan-1/ Đến với bài viết này thì mình muốn cùng các bạn phân tích xem khi nào dùng đến nó nhé! Điều đầu tiên phải nói citus data dùng rất nhiều đối với các ông lớn như Algolia, Heap, Chartbeat, Pex, Mixrank. Đặc điểm chung cho những khách hàng của citus đều là có lượng CCUs rất lớn, và họ cần phân tích dữ liệu big data theo thời gian thực. Một điều nữa là tập khách hàng này của citus đa số sẽ là B2B (Business to Business). Có thể bạn chưa biết đến B2B thì mình xin lấy ví dụ ngắn gọn cho bạn hình dung như sau. Khách hàng trong mô hình B2B ở đây không phải là một cá nhân, mà là một công ty, doanh nghiệp, cửa hàng, do đó có thể giá trị của hợp đồng, đơn hàng thường rất lớn, không thể giao dịch ngay trên sàn thương mại điện tử hoặc kênh thương mại điện tử riêng mà buộc phải ký hợp đồng bên ngoài (trong trường hợp cần thiết). Ví dụ Lazada, Tiki, Adayroi, Shopee,.. ở thị trường Việt Nam. Còn thị trường nước ngoài thì có thể kể đến Amazon, Taobao, Alibaba, Ebay,.. Nói chung theo dân dã thì B2B chính cò trung gian đó mọi người. Quay về citus data thì những khách hàng của họ đã cho ta thấy phần nào được khi nào chúng ta nên sử dụng citus rồi. Hầu hết các ứng dụng B2B đã có khái niệm về người thuê (tenant), khách hàng hoặc tài khoản được tích hợp vào mô hình dữ liệu của họ. Trong mô hình này, cơ sở dữ liệu phục vụ nhiều tenant, mỗi người trong số họ có dữ liệu tách biệt với những người thuê khác. Về khái niệm multi-tenancy thì mình lấy spiderum ra làm ví dụ nhé tuy là nó chỉ gần giống thôi. Mỗi người viết nằm trong nhóm top-user (thành viên nổi bật) sẽ có một domain riêng. Khi bạn vào trang cá nhân của họ thì lập tức spiderum sẽ trỏ tới domain riêng đó. Trong domain đó, mỗi cá nhân người dùng nổi bật sẽ có thể customs trang túy ý của họ và có tập dữ liệu riêng của họ mà không hề chung đụng với bất cứ người dùng nổi bật khác. Bạn hình dung mỗi thành viên nổi bật đó sẽ là một tenant và hệ thống gồm nhiều tenant sẽ là một hệ thống multi-tenancy. Citus cung cấp đầy đủ SQL coverage cho dù nó có workload khá cao. Nó cũng cho phép bạn mở rộng cơ sở dữ liệu quan hệ của bạn đến hơn 100k tenants và nó bổ sung nhiều tính năng mới hỗ trợ multi-tenancy. Ví dụ như citus hỗ trợ việc đóng gói tenants lại nhằm đạt được hiệu suất với số lượng tenants lớn, bên cạnh đó nó cũng tối ưu việc sử dụng những nguồn dữ liệu chung cho những tenants có dùng chung để đơn giản hóa trong quá trình quản lý.Đối với vấn đề tăng khả năng đáp ứng cho phép bạn mở rộng dữ liệu của tenant trên nhiều máy, dễ dàng tăng cpu, ram hay bộ nhớ. Trong tương lai, việc chia sẻ những cơ sở dữ liệu giống nhau giữa nhiều tenants sẽ hiệu quả hơn đối với quản lý phần cứng cũng như đơn giản hóa cơ sở dữ liệu. Một số ưu điểm của citus đối với hệ thống multi-tenancy:- Truy vấn nhanh trên tất cả các tenants- Chia sẻ logic trong cơ sở dữ liệu thay vì trong tầng ứng dụng- Lưu trữ được nhiều dữ liệu hơn so với single node PostgreSQL- Mở rộng cơ sở dữ liệu nhưng vẫn giữa nguyên được dữ liệu SQL gốc ban đầu.- Tăng hiệu năng với CCUs cao- Phân tích tập dữ liệu nhanh- Dễ dàng mở rộng tập khách hàng mới thông qua đăng ký tenant- Đóng gói resource để tái sử dụng cho những tập khách hàng nhỏ và lớn khác nhau. Một điều nữa mà citus đáp ứng cho những nhà phát triển đó là Real-time Analytics (Xây dựng Bảng điều khiển phân tích thời gian thực). Có lẽ đây là một tính năng nổi tập và là ưu điểm hàng đầu mà các nhà phát triển hướng tới khi chọn citus đầu tiên. Vì cho dù có multi-tenancy thì các cơ sở dữ liệu khác cũng có thể làm được, nhưng nếu hướng đến big data và phân tích cơ sở dữ liệu thì có lẽ khách hàng sẽ nhắm tới PostgreSQL và Citus. Ở bài viết này mình chỉ tóm tắt một số nét chính của tính năng Real-time Analytics trong Citus thôi, còn chi tiết và demo mình sẽ đề cập trong bài viết khác nhé Đầu tiên thì bạn hãy tưởng tượng bạn cần truy vấn với một lượng dữ liệu rất lớn từ cơ sở dữ liệu lên với hình thức realtime, tức là vài tích tắc hoặc một giây lại cần truy vấn dữ liệu lên. Với cơ sở dữ liệu thông thường thì thật sự khó đáp ứng vì hệ thống sẽ mất một khoảng thời gian xử lý lọc, sắp xếp, liên kết bảng dữ liệu để có thể đưa lên cho người dùng, mà nó lại xảy ra một cách realtime, lặp đi lặp lại thì bạn nghĩ hệ thống nào chịu cho nổi. Còn một điểm đang ghi nhận nữa là vấn đề tiến trình sự kiện của citus, ví dụ bạn có một khối lượng bảng dữ liệu rất lớn với nhiều node trên nhiều trạm cơ sở dữ liệu khác nhau, khi có một dữ liệu thay đổi hoặc thêm mới, bạn nghĩ bạn sẽ phải cập nhập và thông báo cho các thành phần còn lại không.Thật vậy citus có một cơ chế event (sự kiện) và rollup data (cuộn dữ liệu) giúp bạn phát tín hiện cũng như sắp xếp lại dữ liệu khi có thay đổi hoặc thêm mới trên toàn mạng lưới cơ sở dữ liệu một cách realtime luôn. Bên cạnh việc truy vấn cập nhập dữ liệu một cách đồng thời với chia thành nhiều luồng xử lý, sẽ khiến cho tốc độ truy vấn cũng như ghi và nhận được tăng cao. Việc chia cơ sở dữ liệu theo chiều ngang và đánh index theo thuật toán B-tree cũng giúp cho tốc độ xử lý của citus đáng kinh ngạc. Đúng nghĩa là realtime. Và cái realtime này lại được hỗ trợ trên một dashboard (bảng điều kiển) giúp người dùng có thể phân tích dữ liệu một cách dễ dàng hơn. Có lợi thì cũng có hại, có ưu điểm thì ắt cũng có nhược điểm, dưới đây là một số nhượng điểm và những cân nhắc khi chọn citus vào dự án của mình. Đầu tiên thì bạn thử hỏi xem ứng dụng có bạn có cần thiết áp dụng hệ cơ sở dữ liệu phân tán không, nó tối ưu thì tối ưu thật đó nhưng chi phí cũng như công sức bỏ ra để handle nó không phải là nhỏ, nếu bạn không có nhu cầu scale out (mở rộng) với nhiều node, nhiều worker thì tốt nhất chẳng nên đánh đổi làm gì. Vì thực tế để bảo trì và vận hành hệ cơ sở dữ liệu này rất phức tạp và cần phải có kiến thức không chỉ là Dev hay DBA (Database Administrator) mà còn phải mạnh cả DevOps (Develope + Operation) nữa. Nếu bạn không có nhu cầu phân tích dữ liệu lớn, không có yêu cầu gì về vấn đề realtime analytics thì bạn phân tích dữ liệu offline là đủ, cũng chẳng cần thiết giết gà dùng dao mổ trâu làm gì. Vừa khó khăn trong vấn đề tiếp cận công nghệ mới, vừa chưa chắc đúng mà có khi còn phân tích dữ liệu sai luôn ý Nếu ứng dụng của bạn không cần xử lý đồng thời quá nhiều (a large number of concurrent users) thì bạn cũng chẳng cần quan tâm citus là gì cho mệt. Vì thực sự implement và maintain citus rất cực khổ cho dev. Từ việc handle max_connection, pool_size, dead_lock, rồi linq để có thể truy vấn được dữ liệu khi phân tán như vậy lên tầng ứng dụng rất mất thời gian cũng như công sức. Đó còn chưa kể khi mình tự hanlde hết thì sẽ phát sinh nhiều rủi ro trong logic của bạn. Nếu truy vấn dữ liệu của ban thu thập ETL trả về nhiều kết quả dữ liệu hơn thay vì chỉ tổng hợp và phân tích dữ liệu. Nói sơ qua về ETL (Extract Transform Load) thì nó là quá trình How to dữ liệu được đưa vào từ các nguồn dữ liệu vào kho dữ liệu. Extracts dữ liệu tức là đi thu gom dữ liệu từ nhiều nguồn khác nhau. Transforms dữ liệu tức là chuyển đổi dữ liệu từ mục đích này sang much đích khác nhằm có được dữ liệu nghiệp vụ và phân tích chúng.DW hoặc DWH (Data Warehouse) là kho lưu trữ trung tâm của dữ liệu tích hợp từ một hoặc nhiều nguồn khác nhau. Nhìn hình trên bạn sẽ hiểu quá trình thu thập và phân tích dữ liệu diễn ra như thế nào. Vậy nên khi áp dụng citus thì quá trình thu thập ETL này sẽ gặp khó khăn một chút, do cơ sở dữ liệu phân tán mà. Nên bạn hãy cân nhắc! Trên đây là một số phân tích sơ bộ về Citus Data - Cơ sở dữ liệu phân tán dựa trên PostgreSQL. Hi vọng có thể giúp bạn hiểu được tại sao và khi nào dùng chúng. Bài viết tới mình sẽ đi kỹ hơn về cách xây dựng Citus Data với Net core. Hi vọng được ủng hộ.blog.ntechdevelopers.com
Khoa học - Công nghệ
/khoa-hoc-cong-nghe
Bài viết nổi bật khác
- Hot nhất
- Mới nhất