Đề Xuất 6/2023 # So Sánh Redis, Mysql Và Mongodb # Top 13 Like

Cập nhật nội dung chi tiết về So Sánh Redis, Mysql Và Mongodb mới nhất trên website Cuocthitainang2010.com. Hy vọng thông tin trong bài viết sẽ đáp ứng được nhu cầu ngoài mong đợi của bạn, chúng tôi sẽ làm việc thường xuyên để cập nhật nội dung mới nhằm giúp bạn nhận được thông tin nhanh chóng và chính xác nhất.

Published Sep 22nd, 2019 11:35 PM 2 min read

1. Số liệu thống kê

Số liệu Redis Mongodb MySQL

2. Cấu trúc cơ sở dữ liệu

– Relational DBMS.– MySQL cung cấp một máy chủ cơ sở dữ liệu quan hệ SQL (Ngôn ngữ truy vấn có cấu trúc) rất nhanh, đa luồng, đa người dùng và mạnh mẽ. – MySQL Server được thiết kế cho các hệ thống sản xuất tải trọng nặng, nhiệm vụ quan trọng cũng như nhúng vào phần mềm được triển khai hàng loạt.

3. Một số database models khác

4. Tại sao nên sử dụng?

– Cơ sở dữ liệu NoSQL.– Dễ cài đặt, sử dụng, deploy và duy trì.– Lưu trữ dữ liệu trong bộ nhớ nên cho hiệu năng cao và tốc độ nhanh.– Mã nguồn mở, ổn định, chi phí hiệu quả.– Tính mở rộng và sẵn sàng cao, sao chép bất đồng bộ, …– Tích hợp dễ dàng với Sidekiq cho Rails background job.– Cấu trúc dữ liệu đa dạng, …

– Một trong những document store phổ biến nhất.– NoSQL.– Dễ dàng setup, sử dụng cũng như duy trì.– Mã nguồn mở, miễn phí, đáng tin cậy có tốc độ và hiệu năng nhanh.– Khả năng linh hoạt, mở rộng, sẵn sàng cao, có khả năng auto-sharding.– Hỗ trợ đầy đủ index, tốc độ cập nhật nhanh chóng.

– RDBMS mã nguồn mở được sử dụng rộng rãi.– Cơ sở dữ liệu SQL.– Mã nguồn mở miễn phí, dễ sử dụng, khả năng tương thích cao, hỗ trợ đa nền tảng, cộng đồng phát triển mạnh mẽ.– Hỗ trợ index và full-text searching.– Nhanh, sẵn có và bảo mật.– Một RDBMS mạnh mẽ có số lượng ứng dụng gần như không giới hạn.

5. Khi nào nên sử dụng?

– Dữ liệu key-value.– Caching.– Lo lắng và có thời gian cân nhắc thiết kế cơ sở dữ liệu.– Thực sự cần hiệu năng cao.– Không quan tâm nhiều tới scaling, kích thước dữ liệu ổn định.

– Dữ liệu phức tạp, lớn, đang phát triển.– Linh hoạt, dễ để học.– Prototyping, Startups, Hackathons– Không quan tâm lắm về cơ sở dữ liệu.– Cần thay đổi schema nhanh chóng.– Các hệ thống realtime (thời gian thực) yêu cầu phản hồi nhanh, bigdata với yêu cầu truy vấn nhanh, có tần suất write/insert lớn.– Sử dụng làm search engine.

– Cơ sở dữ liệu quan hệ.– Khi có các hoạt động phân tán.– Cần bảo mật cao và hoạt động đơn giản.– các giải pháp tùy chỉnh.– Không nên sử dụng khi dữ liệu lớn dần và không thể cache hết lên memory.– Cần tuân thủ SQL và sự thi hành đồng thời.

6. Nhược điểm

– Vì Redis sử dụng RAM làm bộ nhớ cho mình nên khi lượng file cache lớn thì sẽ dẫn đến trường hợp thiếu RAM cho Server.– Không thể truy vấn trực tiếp các object.

– Không hỗ trợ JOIN.– Dữ liệu dễ bị sai ro không có ràng buộc.– Sử dụng nhiều bộ nhớ và giới hạn kích thước bản ghi (< 16Mb).

7. Các công ty đã sử dụng

Airbnb, Uber Technologies, Instagram, Medium, Pinterest, Twitter, Reddit, Slack, Instacart, Lyft, Stack Exchange, Shopify, StackShare, Udemy, DigitalOcean , Samsung …

Uber Technologies, Lyft, Codecademy, MIT, Rainist, CircleCI, chúng tôi OpenGov, Hootsuite, Keen, Trello, 500px, nrise, OpenTable, eBay …

Airbnb, Uber Technologies, Netflix, Dropbox, Pinterest, Twitter, Slack, Shopify, LinkedIn, Coursera, Udemy, DigitalOcean, 9GAG, Asana, Yelp …

8. Công cụ tích hợp

Datadog, Presto, EasyEngine, Heroku Redis, Spring Data, Tyk Cloud, OpsDash, SignalFx …

Datadog, Mongoose, Metabase, MongoDB Atlas, JSON, Azure Cosmos DB, Presto, Redash …

9. Một số tiêu chí khác

10. Lãi suất theo thời gian

11. Tham khảo

Redis – Mongobd Mongodb – MySQL – Redis

So Sánh Mongodb Và Mysql: Cở Sở Dữ Liệu Nào Thì Tốt Hơn?

Giới thiệu

Các cơ sở dữ liệu quan hệ giữ vị trí đi đầu trong nhiều thập kỷ và vào thời gian đó là sự lựa chọn là khá rõ ràng MySQL, Oracle hoặc MS SQL.Chúng đã từng là cơ sở cho hàng tấn ứng dụng doanh nghiệp, trong khi các ứng dụng hiện đại đòi hỏi sự đa dạng và khả năng mở rộng hơn.Các cơ sở dữ liệu phi quan hệ, như MongoDB, đã xuất hiện để đáp ứng các yêu cầu đang tồn tại và thay thế môi trường quan hệ hiện tại.

MySQL là gì?

MySQL tương thích với gần như tất cả các hệ điều hành, cụ thể là Windows, Linux, Unix, Apple, FreeBSD và nhiều hệ điều hành khác..Nó hỗ trợ các công cụ lưu trữ khác nhau như InnoDB, Federated, MyISAM, Memory, CSV, Archive, Blackhole và Merge.

MongoDB là gì?

MongoDB là một cơ sở dữ liệu hướng tài liệu mã nguồn mở phổ biến được phát triển bởi 10gen, sau này được gọi là MongoDB Inc. Trong trường hợp này, các tài liệu được tạo và lưu trữ trong các tệp BSON, định dạng Binary JSON (JavaScript Object Notation),vì vậy tất cả các loại dữ liệu JS là được hỗ trợ. Trong trường hợp đó, MongoDB thường được áp dụng cho các dự án chúng tôi Ngoài ra, JSON cho phép chuyển dữ liệu giữa các máy chủ và ứng dụng web bằng cách sử dụng định dạng có thể đọc được. Nó cũng là một lựa chọn tốt hơn, khi nói đến dung lượng và tốc độ lưu trữ, vì nó mang lại hiệu quả và độ tin cậy cao hơn.

Một trong những lợi ích hàng đầu được MongoDB cung cấp là việc sử dụng các lược đồ động giúp loại bỏ nhu cầu xác định trước cấu trúc, như các trường hoặc các loại giá trị. Mô hình như vậy cho phép biểu diễn mối quan hệ phân cấp, lưu trữ mảng và khả năng thay đổi cấu trúc bản ghi bằng cách thêm hoặc xóa các trường. Giải pháp NoQuery này đi kèm với nhúng,auto-sharding, và on-board replication để có khả năng mở rộng tốt hơn và tính sẵn sàng cao.

So sánh MySQL và MongoDB

MySQL và MongoDB: ưu và nhược điểm

So sánh hiệu năng MongoDB và MySQL là khó khăn, vì cả hai hệ thống quản lý đều cực kỳ hữu ích và sự khác biệt cốt lõi làm nền tảng cho các hoạt động cơ bản và cách tiếp cận ban đầu của chúng. Tuy nhiên, MongoDB vs MySQL là một đối số nóng đang diễn ra trong một thời gian: cơ sở dữ liệu quan hệ trưởng thành chống lại một hệ thống phi quan hệ trẻ. Cả hai đều là nguồn mở và dễ dàng có sẵn, cũng như cả hai hệ thống cung cấp các phiên bản thương mại với hàng tấn các tính năng bổ sung.

Hỗ trợ giao dịch Atomic,Hỗ trợ JOIN,Giải pháp Mature,Hệ thống bảo mật đặc quyền và mật khẩu

Xác thực tài liệu,Công cụ lưu trữ tích hợp,Rút ngắn thời gian giữa thất bại chính và phục hồi

MySQL nhược điểm

MongoDB nhược điểm

Mở rộng quy mô,Mối quan tâm ổn định,Phát triển dựa vào cộng đồng

Không phải là lựa chọn tốt nhất cho các ứng dụng có giao dịch phức tạp,Không phải là một thay thế snap-in cho các giải pháp cũ,Giải pháp trẻ

Chọn cơ sở dữ liệu nào?

MongoDB thu hút người dùng với triết lý đơn giản và cởi mở, cũng như cộng đồng hợp tác và hữu ích, trong khi người dùng báo cáo chính xác điều ngược lại về MySQL, sau khi mua lại Oracle. Một vấn đề khác với vấn đề thứ hai là chủ sở hữu tập trung vào phát triển MariaDB cùng với việc từ chối chấp nhận các bản vá cộng đồng và để cung cấp kế hoạch bền vững. Những yếu tố này đã dẫn đến tình trạng bế tắc, mặc dù MySQL vẫn là giải pháp phù hợp cho nhiều công ty trên toàn thế giới.

So sánh tốc độ MongoDB với MySQL, các nhà phát triển lưu ý rằng cái sau thiếu tốc độ và gặp khó khăn với khối lượng dữ liệu lớn, do đó, nó sẽ là lựa chọn tốt hơn cho các công ty có cơ sở dữ liệu nhỏ hơn và tìm kiếm một giải pháp tổng quát hơn. Mặc dù đây là một trong những lợi thế của MongoDB so với MySQL: khả năng đối phó với lượng dữ liệu lớn và không có cấu trúc.

Để trả lời câu hỏi chính: khi nào nên sử dụng MongoDB thay vì MySQL? Bạn cần phải tính đến các yêu cầu dự án của mình và các mục tiêu xa hơn. MySQL được công nhận vì hiệu suất cao, tính linh hoạt, bảo vệ dữ liệu đáng tin cậy, tính sẵn sàng cao và dễ quản lý. Lập chỉ mục dữ liệu phù hợp có thể giải quyết vấn đề với hiệu suất, tạo thuận lợi cho sự tương tác và đảm bảo sự mạnh mẽ. Nhưng nếu dữ liệu của bạn không có cấu trúc và phức tạp, hoặc nếu bạn có thể xác định trước sơ đồ của bạn, thì bạn sẽ chọn tốt hơn cho MongoDB. Và hơn thế nữa, nếu bạn cần xử lý một khối lượng dữ liệu lớn và lưu trữ dưới dạng tài liệu – MongoDB sẽ giúp bạn đáp ứng các thách thức.

Refer: https://da-14.com/blog/mongodb-vs-mysql-comparison-which-database-better

Mongodb Và Mysql Cơ Sở Dữ Liệu Nào Tốt Hơn ?

MySQL là gì ?

MongoDB là gì ?

MongoDB là một cơ sở dữ liệu nguồn mở, không quan hệ được phát triển bởi MongoDB, Inc MongoDB lưu trữ dữ liệu dưới dạng các tài liệu trong một biểu diễn nhị phân được gọi là BSON (Binary JSON). JSON cho phép chuyển dữ liệu giữa các máy chủ và ứng dụng web bằng cách sử dụng định dạng có thể đọc được. Nó cũng là một lựa chọn tốt hơn, khi nói đến dung lượng và tốc độ lưu trữ, vì nó mang lại hiệu quả và độ tin cậy cao hơn.

Không giống như MySQL và các cơ sở dữ liệu quan hệ khác, MongoDB được xây dựng trên kiến trúc hệ thống phân tán chứ không phải là một thiết kế đơn khối, đơn node. Kết quả là, MongoDB cung cấp out-of-the-box quy mô-ra và địa hoá dữ liệu với sharding tự động, và bản sao bộ để duy trì luôn sẵn có.

So sánh MySQL và MongoDB

Tổng quan

MySQLMongoDBKiểuRDBMS (CSDL quan hệ)CSDL không quan hệCác điểm chínhTable , Row ,ColumnCollection , Document, FieldLược đồStrictDynamicCác tính năng chínhTìm kiếm và đánh chỉ số full text ,Hỗ trợ nhân rộng tích hợp, Trigger, SubSELECT,Truy vấn bộ nhớ đệm,Hỗ trợ SSL,Hỗ trợ Unicode,Công cụ lưu trữ khác nhau với các đặc tính hiệu suất khác nhauAuto-sharding,Native replication,Hỗ trợ mô hình dữ liệu nhúng,Chỉ số phụ toàn diện,Hỗ trợ ngôn ngữ truy vấn phong phú,Hỗ trợ công cụ lưu trữ khác nhau

Một số thuật ngữ và khái niệm

MySQLMongoDBACID TransactionsACID TransactionsTableCollectionRowDocumentColumnFieldSecondary IndexSecondary IndexJOINsEmbedded documents, $lookup & $graphLookupGROUP_BYAggregation Pipeline

Tính năng

MySQLMongoDBOpen sourceYesYesACID TransactionsYesNoMô hình dữ liệu linh hoạt NoYesQuản trị SchemaYesYesExpressive joins, faceted search, graphs queries, powerful aggregationsYesYesIdiomatic, native language driversNoYesHorizontal scale-out with data locality controlsNoYes

Truy vấn

Ưu và khuyết điểm của MongoDB và MySQL

MySQL ưu điểmMongoDB ưu điểmHỗ trợ giao dịch Atomic,Hỗ trợ JOIN,Giải pháp Mature,Hệ thống bảo mật đặc quyền và mật khẩuXác thực tài liệu,Công cụ lưu trữ tích hợp,Rút ngắn thời gian giữa thất bại chính và phục hồiMySQL nhược điểmMongoDB nhược điểmMở rộng quy mô,Mối quan tâm ổn định,Phát triển dựa vào cộng đồngKhông phải là lựa chọn tốt nhất cho các ứng dụng có giao dịch phức tạp,Không phải là một thay thế snap-in cho các giải pháp cũ,Giải pháp trẻ

MongoDB và MySQL cơ sở dữ liệu nào tốt hơn ?

Các tổ chức thuộc mọi quy mô đang áp dụng MongoDB vì nó cho phép họ xây dựng các ứng dụng nhanh hơn, xử lý nhiều loại dữ liệu đa dạng và quản lý các ứng dụng hiệu quả hơn theo quy mô. Việc phát triển được đơn giản hóa như các tài liệu MongoDB map tự nhiên cho các ngôn ngữ lập trình hướng đối tượng hiện đại. Sử dụng MongoDB loại bỏ lớp ánh xạ đối tượng phức tạp (ORM) dịch các đối tượng trong mã thành các bảng quan hệ. Mô hình dữ liệu linh hoạt của MongoDB cũng có nghĩa là lược đồ cơ sở dữ liệu của bạn có thể phát triển theo yêu cầu kinh doanh.

Bạn cần phải tính đến các yêu cầu dự án của mình và các mục tiêu xa hơn. MySQL được công nhận vì hiệu suất cao, tính linh hoạt, bảo vệ dữ liệu đáng tin cậy, tính sẵn sàng cao và dễ quản lý. Lập chỉ mục dữ liệu phù hợp có thể giải quyết vấn đề với hiệu suất, tạo thuận lợi cho sự tương tác và đảm bảo sự mạnh mẽ. Nhưng nếu dữ liệu của bạn không có cấu trúc và phức tạp, hoặc nếu bạn có thể xác định trước sơ đồ của bạn, thì bạn sẽ chọn tốt hơn cho MongoDB. Và hơn thế nữa, nếu bạn cần xử lý một khối lượng dữ liệu lớn và lưu trữ dưới dạng tài liệu – MongoDB sẽ giúp bạn đáp ứng các thách thức.

8 Điểm So Sánh Giữa Mysql Và Postgresql Để Chọn Lựa Cái Nào Phù Hợp Hơn.

1. Non-blocking của thao tác DDL

Đầu tiên tôi muốn nói về DDL. Trước hết là MySQL.

Tanaka : MySQL thì tôi nghĩ có lợi điểm là có thể thực thi thao tác nhiều DDL bằng Non-blocking ( tức dù trong transaction nhưng mà block đến bảng là không có). Chức năng này có từ bản MySQL 5.6. Và trong trường hợp mà ALTER TABLE (thay đổi tên cột, thêm cột …) chỉ những cột đối tượng cần xử lý thì nó không build bảng từ số 0 nên tốc độ xử lý nhanh, kéo theo việc sẽ giảm tải cho server.

Vậy còn PostgreSQL thì thao tác DDL như là ALTER TABLE không phải là Non-blocking ？

Sawada : Vâng. Nó tuỳ thuộc vào thực thi câu DDL nào thì sẽ khác nhưng mà thao tác write, ví dụ thêm cột chẳng hạn nó sẽ phát sinh block đến bảng khiến không thể tham chiếu đến nữa.

Tôi nghĩ là cũng sẽ có case mà muốn ALTER TABLE đối với DB production, vậy nên làm theo phương pháp như nào ?

Sawada : Thường thì tool chuyên dùng cho maintain là pg_repack sẽ được sử dụng. Nếu dùng nó thì có thể thực thi thao tác ALTER TABLE một phần hay tiến hành REINDEX bằng cách chỉ lock tối thiểu nhất.

Vậy thì chắc chắn là những kỹ sư mà vận hành PostgreSQL thì chắc là nên ghi nhớ có sự tồn tại của tool đó rồi.

2. Performance của câu DML

Tiếp theo tôi muốn so sánh các loại DML（thao tác dữ liệu）, trước tiên hãy nói về SELECT.

Tanaka : Nếu như là câu SELECT đơn giản thì tôi nghĩ không có sự khác biệt giữa MySQL và PostgreSQL.

Sawada : Chuẩn rồi. Khi đó SELECT không khác biệt gì.

Tanaka : Nhưng nếu mà SELECT mà cần phải sort lượng dữ liệu lớn （sau khi ORDER BY thì lấy tất cả dữ liệu ra chẳng hạn …）thì MySQL sẽ bị chậm. Nguyên do là nếu mà so sánh với PostgreSQL thì MySQL có thuật toán sort không được tốt bằng. MySQL về cơ bản không coi việc sort lượng lớn dữ liệu là use case cần quan tâm.

Câu SELECT với điều kiện như nào thì MySQL mới phát huy điểm mạnh của nó ？

Tanaka : MySQL chuyên về use case như là lấy ra 10 hay 100 dữ liệu đầu tiên, ví dụ như cách của Twitter thì nó sẽ nhanh hơn so với PostgreSQL.

Còn những câu DML khác thì thế nào, ví dụ là UPDATE.

Tanaka : UPDATE thì performance của MySQL sẽ ngon hơn đó.

Sawada: Tôi cũng nghĩ vậy.

Tại sao vậy ？

Sawada : PostgreSQL nếu nói về kỹ thuật thì khi UPDATE sẽ có xử lý gần giống như là khi INSERT. Cụ thể là nó sẽ oánh dấu flag như là delete vào dòng trước khi thay đổi rồi thêm dòng mới mà có dữ liệu sau khi mà thay đổi vào.

Tanaka : Ngược lại thì MySQL sẽ ghi đè đối tượng sẽ được UPDATE nên nó đúng với nghĩa là cập nhật.

Ra là thế, giờ tôi đã hiểu, vậy còn DELETE ？

Tanaka : MySQL có yếu điểm là DELETE chậm. Lý do là nó sau khi xoá dữ liệu sẽ thực hiện oánh lại secondary index (tất cả index ngoại trừ cluster index) bằng xử lý đồng bộ nên sẽ tốn thời gian cho xử lý đó. Nhưng ở bản 5.5 đã được cải thiện cũng tương đối bởi change buffer bất đồng bộ của secondary index (nó làm dạng mà buffering thay đổi đến secondary index, rồi khi server ở trạng thái idle thì mới merge nội dung thay đổi), cái đó khác hiệu quả. Kết luận là việc DELETE chậm không còn nhưng bạn sẽ chọn đúng phiên bản từ 5.5 trở lên.

3. Thuật toán JOIN

Kế tiếp chúng ta hãy so sánh JOIN. Tôi thấy có 3 thuật toán hay được dùng là Nested Loop Join, Hash Join và Sort Merge Join.

Tanaka : MySQL cơ bản chỉ support Nested Loop Join. Bởi lẽ MySQL được thiết kế theo quan điểm là không support thuật toán phức tạp.

Tại sao MySQL lại có quan điểm như vậy ？

Tanaka : Trước khi được dùng cho các ứng dụng Web thì MySQ vốn dĩ đã được dùng trên các hệ thống dạng Insert, nó cần chạy DB trên memory hay disk mà có dung lương rất nhỏ nên phải bỏ qua các thuật toán phức tạp

Đã hiểu, thế còn PostgreSQL ？

Sawada : PostgreSQL thì khác, nó support cả 3 luôn.

Với mỗi pattern đó thì nó hướng theo những use case nào ？

Sawada : Khi mà lượng dữ liệu cần JOIN nhiều thì Hash Join và Sort Megre Join hay được dùng. Trường hợp dữ liệu đó đã được sort thì Sort Merge Join sẽ ngon còn không thì tôi khuyên dùng Hash Join. Nested Loop Join sẽ được chọn khi mà lượng dữ liệu của các bảng được JOIN nó đều ít hoặc bảng ít bảng nhiều. Hoặc là trường hợp như bên MySQL là lúc có thể sử dụng index scan ở phía bảng inner.

4. Xử lý transaction

Tiếp theo, tôi muốn hỏi về xử lý transaction. Vì tôi từng nghe đến là xử lý transaction của PostgreSQL với MySQL là khác nhau.

Tanaka : Vâng, MySQL mặc định là REPEATABLE-READ. Với phương thức này thì dữ liệu đối đượng được đọc sẽ hoàn toàn không phải bận tâm là nó sẽ được thay đổi mất ở một transaction khác. Nhưng mà phantom-read ( hiện tượng mà dữ liệu đã được thêm bởi transaction khác lại được thấy khi chạy transaction), để tránh nó thì hiện MySQL đang dùng Next key locking

Nó như thế nào ？

Tanaka : Khi mà transaction đang chạy thì nó sẽ gán lock increment key chính để record không tăng lên. Nhưng cũng chính vì cơ chế như vậy mà có thể lại gây vấn đề khác. Ví dụ như là sử dụng SELECT FOR UPDATE chẳng hạn, mà trong mệnh đề WHERE sử dụng dấu nhỏ hơn < để tìm kiếm records mà dưới 10 thì tất cả các key trên 10 đều bị locking. Khi này thì không thể phát sinh thêm key mới nữa khiến không thể INSERT được dữ liệu, nên các bạn khi dùng cần phải để ý đến nó. Để giảm conflict về locking thì cũng có case đổi sang dùng đến READ-COMMITTED（hình thức lấy dữ liệu mới nhất đã commit）.

Vậy PostgreSQL thì mặc định xử lý transaction là gì ？

Sawada : Là READ-COMMITTED. Trường hợp là hình thức này thì có khả năng xảy ra vấn đề phantom-read hay non-repeatable-read ( là hiện tượng mà trong cùng 1 transaction đọc cùng dữ liệu mà giá trị là thay đổi）. Và với PostgreSQL nếu mà đổi sang REPEATABLE-READ thì sẽ không có next key locking nên tránh được phantom-read, do đó tôi nghĩ về việc dễ tránh conflict thì nó ngon hơn là MySQL.

5. Store proceduce, trigger

Về Store Procedure các bạn nghĩ sao？

Sawada : PostgreSQL có lợi điểm là ngoài SQL thì còn có thể sử dụng cả procedure bên ngoài như là dùng Python …

Tanaka : MySQL thì chỉ có SQL thôi. Ngoài ra, nó còn có điểm yếu ở trên mỗi MySQL thì không thể thực thi step của store procedure được.

Còn trigger？

Tanaka : Với bản trước MySQL 5.6 thì đã có điểm yếu là đối với 1 bảng chỉ được gán tối đa là 6 trigger. Và riêng với BEFORE INSERT TRIGGER thì con số đó chỉ là 1 mà thôi, khá là hạn chế. Hiện tại thì hạn chế này đã hết, nhưng trigger của MySQL chỉ có FOR EACH ROW, còn FOR EACH STATEMENT không có nên cũng cần đánh giá điểm đó khi cần dùng.

6. Dạng logic và vật lý của replication.

Tiếp đến là về replication.

Tanaka : Trường hợp của MySQL thì replication dạng logic (copy câu SQL) hay vật lý (copy image dòng sau khi thay đổi) là có thể chọn lựa. Vốn dĩ, dạng logic là setting mặc định nhưng mà từ MySQL 5.7 về sau thì dạng vật lý đã là mặc định.

Sawada : PostgreSQL thì chỉ có dạng vật lý thôi. Nhưng mà bản release beta version 10 thì có thể dùng cả dạng logic.

Trên MySQL thì dạng vật lý đã thành mặc định nhưng vì lý do gì mà dạng logic bị thất sủng？

Tanaka : Dạng logic có cả tốt lẫn không tốt, ví dụ các bảng của master có ít nhiều sai khác với slave thì khi chạy SQL cũng không có lỗi. Với spec như thế nó có thể vận dụng được khá thoải mái nhưng chính thế mà nó có khả năng không thể tìm ra được sự sai khác giữa master và slave. Vì vậy nên để an toàn thì đã đổi sang dạng vật lý làm mặc định.

7. Chức năng tiện lợi mà chỉ có trong 1 bên.

Tôi muốn hỏi có chức năng tiện lợi nào mà chỉ có trong 1 bên thôi không ？

Tanaka : Bên PostgreSQL thì có hàm window có thể apply hàm tổng hợp thành set kết quả mà đã được phân chia theo từng phần, hay mệnh đề WITH có thể tạo sub query trước khi thực hiện SELECT. Do đó về mặt phân tích thì PostgreSQL mạnh hơn. Nhưng ở bản MySQL 8.0 sẽ dự định đưa vào mấy chức năng hay ho đó

Vậy thì tương lai về mặt phân tích sẽ không có khác biệt nhỉ. Thế còn cái gì khác nữa không？

Sawada : Đó là query song song. Cái này nó giúp làm tăng tốc độ xử lý lên bằng cách dùng nhiều CPU để chạy query. Và rất nhiều kỹ sư đã nêu ra lý do họ chọn PostgreSQL là có OSS tool của bên thứ 3 là PostGIS, nó chuyên dùng để handle thông tin như dữ liệu hình học, bản đồ … Bởi thế mà tôi nghĩ chính sự đa dạng, phong phú của tools là điểm hơn của PostgreSQL so với MySQL.

Tanaka : PostgreSQL có chức năng mà tôi khá là ghen tị đó là pg_basebackup, nó thực sự quá tiện luôn. Do ta hoàn toàn có thể base backup DB online hay trên remote được. Với MySQL thì chỉ có backup vật lý online bằng XtraBackup hay Enterprise Backup nên không thể thực hiện base backup online hay trên remote. được.

8. Về sự lỏng lẻo của loại dữ liệu, thay đổi loại, so sánh chuỗi

Cuối cùng hãy cho tôi hỏi về dự lỏng lẻo của loại dữ liệu ( sự thay đổi loại được thực thi một cách ngầm định, hay sự nghiêm ngặt khi so sánh chuỗi …)

Trường hợp MySQL thì nó nghĩ là cả 3 đều có cùng giá trị.

Thật á, tại sao như thế？

Tanaka : Khi mà số 「1」với chuỗi 「1」thì ngầm định là chuỗi đã được đổi sang dạng số nên chúng bằng nhau. Và khi so sánh số 「1」 với chuỗi「1Q84」thì 「1Q84」ngầm định được đổi thành số. Do nó đọc dữ liệu từ phía trước rồi nó sẽ biến đổi những cái mà có thể đổi sang số được.

Ra là thế, vậy 「1Q84」có thể đọc là「1」

Tanaka : Đúng thế, do đó nó nhận định rằng cả 3 đều bằng nhau mất tiêu luôn. Ngoài ra thì cũng có case biến đổi ngầm định giống vậy, như dạng ngày tháng 「2017-07-01」mà trừ đi số「1」thì số nguyên sẽ được trả về. Do spec như vầy nên các bạn cần chú ý là nó có thể gây bug.

PostgreSQL có biến đổi dữ liệu như thế không ？

Sawada : PostgreSQL khá là nghiêm ngặt với những biến đổi dạng dữ liệu. Như cái mà Tanaka vừa nói về đổi ngày tháng sang số nguyên thì hoàn toàn không có ngầm định xảy ra mà phải do người viết SQL thực hiện rõ ràng cast dữ liệu, việc này hoàn toàn do user định nghĩa chứ bản thân PostgreSQL không tự làm.

Thế còn việc so sánh chuỗi ？

Tanaka : MySQL với setting mặc định sẽ không phân biệt hoa thường. Ngoài ra, từ bản 8.0 sẽ không còn phân biệt âm đục và bán âm đục. Do đó mà 「は」(ha) với「ぱ」(pa) với「ば」(ba) là bằng nhau, cũng như 「びょういん」(byouin) với 「びよういん」(biyouin) sẽ như nhau cả.

Tại sao lại có spec như thế ？

Tanaka : Vì nó phụ thuộc vào spec của Unicode. Unicode được chia ra 4 cấp từ 1 đến 4 về setting của sự nghiêm ngặt trong thứ tự đối chiếu. Để mà phân biệt「は」(ha) với 「ぱ」(pa) với 「ば」(ba) thì cần so sánh ở cấp 2 là「びょういん」(byouin) với 「びよういん」(biyouin), và cần tiếp cấp 3 để phân biệt cấp 2 đó nhưng với setting mặc định của MySQL nó chỉ thực hiện ở cấp 1 nên chúng là như nhau. Do để chính xác thì xử lý sẽ nặng nề vì cần tăng cấp so sánh nên theo quan điểm thiết kế đơn giản cho tốc độ nhanh.

Thật là thú vị.

Vậy kết luận ở đây sẽ là chọn cái nào cho service như thế nào？

Tôi muốn tổng quan lại, giữa PostgreSQL và MySQL thì khi nào sẽ chọn cái nào？

Sawada : PostgreSQL có điểm mạnh là lớn nhất là nhiều chức năng nên hệ thống nào cần nhiều chức năng hỗ trợ thì nó có lẽ sẽ phù hợp hơn. Ví dụ như khi chuyển từ Oracle Database sang, hay những doanh nghiệp hệ SIer (System Integration-er). Sau nữa là hệ phân tích cũng dùng nhiều.

Phía MySQL thì sao？

Tanaka : Cơ bản thì tôi nghĩ MySQL phù hợp đối với những dịch vụ web đơn giản, tức hệ thống mà lấy ra lượng dữ liệu nhất định rồi hiển thị ra. Giống như bên Twitter chỉ hiển thị phần đầu của timeline và chỉ khi scroll xuống mới lấy set dữ liệu tiếp theo, những ẻm như thế thì rất hợp với ông MySQL. Nhưng về sau khi nâng version thì có lẽ cả PostgreSQL lẫn MySQL cũng sẽ có nhưng tính năng được nâng cấp tốt hơn. Và lúc đó ai thích cái nào thì dùng do không còn nhiều khác biệt.

Một kết luận thật ‘hoà bình’. Xin cảm ơn cả hai khách mời rất nhiều !

Nguồn : employment.en-japan.com

Bạn đang đọc nội dung bài viết So Sánh Redis, Mysql Và Mongodb trên website Cuocthitainang2010.com. Hy vọng một phần nào đó những thông tin mà chúng tôi đã cung cấp là rất hữu ích với bạn. Nếu nội dung bài viết hay, ý nghĩa bạn hãy chia sẻ với bạn bè của mình và luôn theo dõi, ủng hộ chúng tôi để cập nhật những thông tin mới nhất. Chúc bạn một ngày tốt lành!