PHẦN 1
Part 3: Return of the SQL – Sự trở lại của SQL
Sau khi bị cám dỗ lạc vào trong đêm tối, công đồng software bắt đầu nhìn thấy ánh sáng và trở về với SQL.
Tiếp theo đó sự trỗi dậy của NewSQL mới: Một databases có khả năng mở rộng và hoàn toàn dành cho SQL. H-Store (2008), thành quả của các nhà nghiên cứu của MIT và Brown, là một trong những OLTP databases đầu tiên. Google tiếp tục dẫn đầu cuộc đua với SQL-interfaced database trong Spanner, theo sau đó là CockroachDB (2014).
Cùng lúc đó, cộng đồng PostgreSQL bắt đầu sống lại, thêm vào những tính năng vô cùng quan trọng như JSON datatype (2012), cũng như trong PostgreSQL 10: native support tốt hơn, text search support cho JSON, và nhiều hơn nữa. Các công ty khác như CitusDB (2016) và yours truly (TimescaleDB) cũng đã tiềm ra cách máy để mở rộng PostgreSQL để tập trung vào data workloads.
Hơn thế TimescaleDB cũng như tấm gương phản chiếu lịch sự của chính SQL. Khi trong nhưng phiên bản đầu tiên, TimescaleDB cũng sử dụng ngôn ngữ query từa tựa SQL gọi là “ioQL.”. Ban đầu, chúng tôi cũng bị cám dỗ và nghĩ việc tạo ra một ngôn ngữ riêng đầy mạnh mẽ thật sự rất có ích. Nhưng khi bắt đầu đi sâu thì nó có rất nhiều vấn đề nảy sinh từ thuật toán cho đến việc hướng dẫn user.
Và sau một thời gian, chúng tôi nhận ra rằng việc tạo ra một ngôn ngữ mới hoàn toàn phí công và ta nên tìm cách để thật sự sử dụng SQL. Ngay lập tức một thế giới mới như mở ra trước mắt chúng tôi. Hiện nay, dù database chỉ mới được 5 tháng nhưng các user đã có thể làm nhiều việc khác nhau như visualization tools (Tableau), kết nối tới ORMs, etc…
Hãy dõi theo Google
Google rõ ràng là người dẫn đầu trong cuộc thi công nghệ trong hơn một thập kỉ vừa qua. Do đó, khi nói đến việc tìm hiểu về công nghệ mới thì không có gì hơn việc theo dõi nguồn tin từ ông lớn công nghệ này.
Hãy thử xem Spanner của Google (Spanner trở thành một SQL System, 2017), và bạn sẽ nhận thấy rất nhiều chi tiết thú vị.
Ví dụ như khi Google bắt đầu tạo nó trên Bigtable, họ phát hiện ra việc thiếu SQL gây ra nhiều vấn đề nhức đầu:
“Trong khi những hệ thống này cung cấp một vài lợi ích của một database system, chúng lại thiếu nhiều database feature mà các developer vẫn thường hay dựa vào. Do không có một ngôn ngữ query mạnh mẽ nên developer phải bỏ ra rất nhiều thời gian cũng như phải thực hiện nhiều bước phức tạp. Do đó mà chúng tôi đã quyết định biến Spanner thành full featured SQL system, với query execution được tích hợp chặt trẽ với các tính năng khác của Spanner”
Sau đó, hãng cũng nói rõ thêm vì sao lại lựa chọn chuyển đổi từ NoSQL qua SQL:
“API của Spanner cung cấp NoSQL methods cho point lookup và range scan. Trong khi NoSQL methods cung cấp một cách thức đơn giản để launch Spanner, và tỏ ra rất hữu ích trong những trường hợp đơn giản, SQL vẫn đưa ra những giá trị vô cùng to lớn khi có khả năng xử lí các data access pattern phức tạp và push thuật toán tới data.”
Không chỉ dừng lại với spanner mà SQL còn được Google áp dụng vào nhiều system của hãng:
“SQL engine của Spanner cùng sử dụng chung một SQL dialect, được gọi là “Standard SQL”, cùng với các hệ thống nội bộ khác tại Google như F1 và Dremel cũng như hệ thống bên ngoài như BigQuery…
Với user trong Google, nó giúp giảm độ phức tạp khi làm việc giữa nhiều hệ thống khác nhau. Một developer hay nhà phân tích data khi viết SQL cho Spanner database vẫn có thể chuyển qua Dremel mà không phải lo về sự khác biệt trong ngôn ngữ”.
Cách tiếp cận này đã thành công vượt ngoài tưởng tượng với spanner đóng vai trò chủ chốt trong hệ thống của Google, bao gồm AdWords và Google Play, “Các khách hàng đám mây điển tử cũng rất quan tâm và thích thú với SQL.”
Điều này có ý nghĩa gì cho tương lai?
Trong computer networking, có một thuật ngữ gọi là “eo hẹp”
Nó ám chỉ việc trong hệ thống network với nhiều lớp hardware ở dưới và software ở trên. Mỗi phần cứng và phần mềm luôn khác biệt nhau nên ta phải bảo đảm bất kể là phần cứng gì thì phần mềm vẫn có thể kết nối với network. Ngược lại, bất kể phần mềm nào thì phần cứng vẫn xử lí được network requests.
Trong networking, vai trò của “eo hẹp” được thực hiện bởi Internet Protocol (IP) như một interface thông thường giữ networking protocols cấp thấp (dành cho local-area network) và application and transport protocols cấp cao. có thể nói IP đóng vai trò như người thông dịch cho phép kết nối và giao tiếp giữa các thiết bị.
Chúng tôi tin rằng SQL đã trở thành “eo hẹp” trong phân tích data
Chúng ta đang sống trong thời đại mà data chính là nguồn tư liệu quí giá nhất. Kết quả là sự bùng nổ về databases (Olap, time-series, tài liệu, graph, etc), tools xử lí data (Hadoop, Spark, Flink), data buses (Kafka, RabbitMQ), etc. Đồng thời chúng ta có ngày càng có nhiều app dựa trên cấu trúc data này.
Tương tự như network chúng ta cũng có một stack phức tạp với cơ sở ở dưới và app ở trên. Do đó mà ta thường phải viết khá nhiều code để gắn chúng lại với nhau. Nhưng những code thì rất dễ “vỡ” nên đòi hỏi phải được chăm sóc và bảo trì.
Điều chúng ta cần là một interface chung để các phần trong stack trên có thể giao tiếp với nhau. Và sẽ là rất lí tưởng khi ta có một interface chuẩn cho phép việc thay ra/vào các thành phần mà không phải lo về việc crash hoặc lỗi.
Đây chính là lúc SQL tỏa sáng bởi cũng như IP, SQL là một interface chuẩn chung.
Không những thế mà SQL còn rất dễ đọc
SQL đã quay trở lại
SQL đã trở lại. Không phải chỉ vì NoSQL quá ư là tởm lợm. Cũng không phải chỉ do việc phải học ngôn ngữ mới quá phiền phức. Cũng không phải chỉ là do SQL đạt chuẩn.
Mà còn là vì thế giới này tràn ngập Data. chúng ở khắp mọi nơi và liên kết lẫn trói buộc chúng ta. Ban đầu ta có thể dựa vào các giác quan và não để giải quyết. Sau đó, khi mà máy móc trở nên thông minh hơn thì chúng thay ta làm những công việc này. Việc có thể xử lý càng nhiều data càng giúp chúng ta có khả năng nhận thức cao hơn, rõ ràng hơn và đồng thời nó khiến cho hệ thống lưu trữ data phát triển hơn bao giờ hết.
Chỉ có 2 lựa chọn cho chúng ta: phải sống trong một thế giới với đống data lộn xộn, code dễ hư với hàng triệu interface khác nhau, hoặc là chọn SQL và thống nhất mọi thứ.
Nguồn: TopDev via timescale
