thảo luận Tất tần tật về NewSQL

RPG29 · 7/4/23

Hello các anh em, mình search thử thì chưa thấy topic chủ đề NewSQL nên lập luôn :adore:

Không biết có anh em nào chạy production mấy DMBS (NewSQL) thế hệ mới như CockroachDB, YugabyteDB... chưa nhỉ cho mình xin ít đánh giá về performance, operation... etc.

Hiện tại mình đang follow một project có thành phần đòi hỏi phải sử dụng CockroachDB, thằng này thì mình chưa dùng bao giờ nên hơi e ngại về nó. Hiện đang trong giai đoạn research nên muốn tham khảo ý kiến người đi trước :adore:

doanxemnao · 7/4/23

Quả tít vloz đấy

Raiha173 · 7/4/23

Chơi đi bác

nếu use case hợp thì ngại gì không thử, cái nào ko hợp thì lại tách ra chơi polygot persistence

RPG29 · 9/4/23

Cảm quan thì thấy CockroachDB dễ setup. Ai dùng Consul, Etcd... rồi thì thấy tương tự.
Có thể setup multiple DC, multiple Region dễ dàng.
API thì compatibility với Postgres nên có thể dùng chung driver.
:adore:

thang236n3 · 10/4/23

vote chơi, đợt này e cũng đang xem thử mấy đội này, thấy có 1 công ty ở vn đã áp dụng vào prod rùi

quangtung2912 · 6/5/23

Google Spanner nó dùng Atomic Clock mới đảm bảo được tính chất Linearizablility. Không hiểu ông CockroachDB này làm thế nào.
Nghe nói Hybrid Clock gì gì đó mà đọc paper gốc của Spanner đã ngấp ngoải rồi nên chịu chưa dám động đến db này.

Mà có vẻ TiDB dễ hiểu hơn. Cũng là NewDB. Shopee, ZaloPay, NinjaVan có vẻ có dùng

RPG29 · 28/7/23

Đá lên phát :adore:

Sau một thời gian trải nghiệm qua một số side project thì mình thấy CockroachDB, YugabyteDB phù hợp với các project mới tinh, ko đòi hỏi Postgres compatibility cao. Còn các project mà đang sử dụng nhiều feature đặc trưng của Postgres thì rất phiền.

Cockroach thì reimplement lại các feature của Postgres trên tầng raft, distributed storage. Chỉ compatible với Postgres ở mức protocol nên nhiều query không thể chạy dc.

Yugabyte khá hơn vì nó bưng nguyên cái engine của Postgres 11 qua dùng, thay thế tầng storage bằng phiên bản distributed. Do build trên Postgres 11 nên compatibility tốt hơn nhiều.

Cockroach dễ setup hơn Yugabyte tẹo. Cockroach thì phải đi kèm với một cái proxy như HAProxy để load balancing các node. Yugabyte thì có driver riêng hỗ trợ load balancing luôn.

Túm lại là Postgres vẫn phù hợp với đại đa số hơn, còn đám distributed SQL database thì phải custom kiến trúc hệ thống ít nhiều mới dùng dc, ko phải dạng drop in replacement cho các SQL DMBS truyền thống.

quangtung2912 · 28/7/23

À có ai đang tìm hiểu Vitess không?
Thấy dùng MySQL làm core DB rồi build lên mấy cái như Proxy, Sharding, HA dùng semi-sync.
Chắc dễ migrate hơn dùng hẳn một DB mới. Có lẽ cũng an toàn hơn vì ít nhất còn là MySQL ở dưới. Nhiều công ty còn dùng làm core DB như JD.com, github, slack, pinterest,... Trước có ông YouTube dùng cả chục năm trời rồi chuyển sang Spanner năm 2019.
Ở trên có bảo các công ty có dùng TiDB nhưng hình như toàn không phải phần core vì Engine hoàn toàn mới có vấn đề gì mất dữ liệu core thì chịu. Người ta còn bảo Storage Engine mới phải cần ít nhất 10 năm mới Mature

GeniVN · 29/7/23

quangtung2912 đã nói:
À có ai đang tìm hiểu Vitess không?
Thấy dùng MySQL làm core DB rồi build lên mấy cái như Proxy, Sharding, HA dùng semi-sync.
Chắc dễ migrate hơn dùng hẳn một DB mới. Có lẽ cũng an toàn hơn vì ít nhất còn là MySQL ở dưới. Nhiều công ty còn dùng làm core DB như JD.com, github, slack, pinterest,... Trước có ông YouTube dùng cả chục năm trời rồi chuyển sang Spanner năm 2019.
Ở trên có bảo các công ty có dùng TiDB nhưng hình như toàn không phải phần core vì Engine hoàn toàn mới có vấn đề gì mất dữ liệu core thì chịu. Người ta còn bảo Storage Engine mới phải cần ít nhất 10 năm mới Mature

vitess bọn planetscale đang dùng thì phải, có vẻ khá ổn. Nếu chủ yếu dữ liệu bác là transactional thôi thì múc luôn. Còn TiDB thì có thêm 1 cục để làm analytical nữa, kiểu hybrid

Con engine của nó là TiKV, có vẻ cũng ổn định, còn mất dữ liệu k thì em k biết

RPG29 · 30/7/23

quangtung2912 đã nói:
À có ai đang tìm hiểu Vitess không?
Thấy dùng MySQL làm core DB rồi build lên mấy cái như Proxy, Sharding, HA dùng semi-sync.
Chắc dễ migrate hơn dùng hẳn một DB mới. Có lẽ cũng an toàn hơn vì ít nhất còn là MySQL ở dưới. Nhiều công ty còn dùng làm core DB như JD.com, github, slack, pinterest,... Trước có ông YouTube dùng cả chục năm trời rồi chuyển sang Spanner năm 2019.
Ở trên có bảo các công ty có dùng TiDB nhưng hình như toàn không phải phần core vì Engine hoàn toàn mới có vấn đề gì mất dữ liệu core thì chịu. Người ta còn bảo Storage Engine mới phải cần ít nhất 10 năm mới Mature

Bọn TiDB, CockroachDB... chỉ compatibility ở mức nào đó thôi chứ ko 100% cho nên hệ thống nào đang tích hợp sâu với tầng DB sợ lắm. Dùng các giải pháp sharding như Vitess, Citus... an toàn hơn.

Btw bọn distributed SQL có một lợi thế tuyệt đối là operation siêu dễ. Scale up/down, add node, remove node, rebalance, upgrade dễ như không và có thể thực hiện zero-downtime - việc mà đám DBMS truyền thống làm rất khó.

Nepgear. · 30/7/23

Đang sử dụng SurrealDB (https://surrealdb.com/), viết = Rust. Tình hình là vẫn beta nên doc chưa đầy đủ, nhất là distributed parts.

1 cái rất thích là chạy serverless hoàn toàn dc vì thằng này nó built in authentication, authorization. Nó vừa là sql vừa là nosql, relation qua graph xịn và avoid dc cái N+1 query,...

https://surrealdb.com/features

Connection thì RPC (default), restful.

quangtung2912 · 30/7/23

GeniVN đã nói:
vitess bọn planetscale đang dùng thì phải, có vẻ khá ổn. Nếu chủ yếu dữ liệu bác là transactional thôi thì múc luôn. Còn TiDB thì có thêm 1 cục để làm analytical nữa, kiểu hybrid Con engine của nó là TiKV, có vẻ cũng ổn định, còn mất dữ liệu k thì em k biết

PlanetScale là kiểu serverless offering cho Vitess với cả cũng là maintainer chính của nó.
Thấy cho phép add node / remove node, online schema change các thứ khá ổn. Chỉ là đoạn rebalancing thì không được full tự động như mấy ông Distributed SQL.
TiDB dùng mô hình Percolator cảm giác cứ không được high performance thế nào ấy. Phụ thuộc nhiều vào Time Oracle. Cũng không thấy sau này mấy paper của Google dùng mô hình Percolator nữa?
Ưu điểm của TiDB là có global transaction nhưng nhược điểm lại chính là chỉ có global transaction.
Không có kiểu entity group với local transaction như Vitess. Vitess lại k có global transaction =))

)

Nói chung thấy có vẻ Vitess high performance hơn, scale tốt hơn, an toàn khi apply vào production hơn nhưng khó dùng hơn.

thảo luận Tất tần tật về NewSQL

RPG29

Đã tốn tiền

doanxemnao

Senior Member

Raiha173

Member

RPG29

Đã tốn tiền

thang236n3

Senior Member

quangtung2912

Senior Member

RPG29

Đã tốn tiền

quangtung2912

Senior Member

GeniVN

Senior Member

RPG29

Đã tốn tiền

Nepgear.

Member

quangtung2912

Senior Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này