Đóng góp của Yandex cho các cơ sở dữ liệu sau sẽ được xem xét.
- ClickNhà
- Odyssey
- Khôi phục về một thời điểm (WAL-G)
- PostgreSQL (bao gồm logerrors, Amcheck, heapcheck)
- quả mận xanh
Video:
Chào thế giới! Tên tôi là Andrey Borodin. Và những gì tôi làm tại Yandex.Cloud là phát triển cơ sở dữ liệu quan hệ mở vì lợi ích của khách hàng Yandex.Cloud và Yandex.Cloud.
Trong buổi nói chuyện này, chúng ta sẽ nói về những thách thức mà cơ sở dữ liệu mở ở quy mô lớn phải đối mặt. Tại sao nó lại quan trọng? Bởi vì nhỏ, vấn đề nhỏ mà, như muỗi, rồi thành voi. Chúng trở nên lớn khi bạn có nhiều cụm.
Nhưng đó không phải là điều chính. Những điều đáng kinh ngạc xảy ra. Những điều xảy ra chỉ một trong một triệu trường hợp. Và trong môi trường đám mây, bạn phải chuẩn bị cho điều đó, bởi vì những điều khó tin có thể xảy ra rất cao khi có thứ gì đó tồn tại ở quy mô lớn.
Nhưng! Ưu điểm của cơ sở dữ liệu mở là gì? Thực tế là bạn có cơ hội về mặt lý thuyết để giải quyết bất kỳ vấn đề nào. Bạn có mã nguồn, bạn có kiến thức lập trình. Chúng tôi kết hợp nó và nó hoạt động.
Có những cách tiếp cận nào khi làm việc trên phần mềm nguồn mở?
- Cách tiếp cận đơn giản nhất là sử dụng phần mềm. Nếu bạn sử dụng các giao thức, nếu bạn sử dụng các tiêu chuẩn, nếu bạn sử dụng các định dạng, nếu bạn viết các truy vấn trong phần mềm nguồn mở, thì bạn đã hỗ trợ nó rồi.
- Bạn đang làm cho hệ sinh thái của nó lớn hơn. Bạn làm cho khả năng phát hiện sớm lỗi cao hơn. Bạn tăng độ tin cậy của hệ thống này. Bạn tăng sự sẵn có của các nhà phát triển trên thị trường. Bạn cải thiện phần mềm này. Bạn đã là một người đóng góp nếu bạn vừa mới tạo dựng được phong cách và mày mò điều gì đó ở đó.
- Một cách tiếp cận dễ hiểu khác là tài trợ cho phần mềm nguồn mở. Ví dụ: chương trình Google Summer of Code nổi tiếng, khi Google trả cho một số lượng lớn sinh viên từ khắp nơi trên thế giới số tiền dễ hiểu để họ phát triển các dự án phần mềm mở đáp ứng các yêu cầu cấp phép nhất định.
- Đây là một cách tiếp cận rất thú vị vì nó cho phép phần mềm phát triển mà không cần chuyển trọng tâm ra khỏi cộng đồng. Google, với tư cách là một gã khổng lồ công nghệ, không nói rằng chúng tôi muốn tính năng này, chúng tôi muốn sửa lỗi này và đây là lúc chúng tôi cần đào sâu. Google nói: “Hãy làm những gì bạn làm. Chỉ cần tiếp tục làm việc theo cách bạn đang làm và mọi thứ sẽ ổn thôi”.
- Cách tiếp cận tiếp theo để tham gia vào nguồn mở là sự tham gia. Khi bạn gặp vấn đề trong phần mềm nguồn mở và có nhà phát triển, nhà phát triển của bạn bắt đầu giải quyết vấn đề. Chúng bắt đầu làm cho cơ sở hạ tầng của bạn hiệu quả hơn, các chương trình của bạn nhanh hơn và đáng tin cậy hơn.
Một trong những dự án Yandex nổi tiếng nhất trong lĩnh vực phần mềm nguồn mở là ClickHouse. Đây là cơ sở dữ liệu ra đời nhằm đáp lại những thách thức mà Yandex.Metrica đang phải đối mặt.
Và với tư cách là một cơ sở dữ liệu, nó được tạo bằng nguồn mở để tạo ra một hệ sinh thái và phát triển nó cùng với các nhà phát triển khác (không chỉ trong Yandex). Và bây giờ đây là một dự án lớn có sự tham gia của nhiều công ty khác nhau.
Trong Yandex.Cloud, chúng tôi đã tạo ClickHouse trên Bộ lưu trữ đối tượng Yandex, tức là trên bộ lưu trữ đám mây.
Tại sao điều này lại quan trọng trong đám mây? Bởi vì bất kỳ cơ sở dữ liệu nào cũng hoạt động trong tam giác này, trong kim tự tháp này, trong hệ thống phân cấp loại bộ nhớ này. Bạn có các thanh ghi nhanh nhưng nhỏ và ổ SSD, ổ cứng lớn nhưng chậm giá rẻ và một số thiết bị khối khác. Và nếu bạn làm việc hiệu quả ở đỉnh kim tự tháp thì bạn có cơ sở dữ liệu nhanh. nếu bạn làm việc hiệu quả ở phần dưới cùng của kim tự tháp này thì bạn có cơ sở dữ liệu được chia tỷ lệ. Và về vấn đề này, việc thêm một lớp khác từ bên dưới là một cách tiếp cận hợp lý để tăng khả năng mở rộng của cơ sở dữ liệu.
Làm thế nào nó có thể được thực hiện? Đây là một điểm quan trọng trong báo cáo này.
- Chúng tôi có thể triển khai ClickHouse qua MDS. MDS là giao diện lưu trữ đám mây Yandex nội bộ. Nó phức tạp hơn giao thức S3 thông thường nhưng phù hợp hơn với thiết bị khối. Nó là tốt hơn để ghi lại dữ liệu. Nó đòi hỏi phải lập trình nhiều hơn. Lập trình viên sẽ lập trình, thậm chí còn tốt, thú vị.
- S3 là một phương pháp phổ biến hơn giúp giao diện đơn giản hơn nhưng ít thích ứng hơn với một số loại khối lượng công việc nhất định.
Đương nhiên, vì muốn cung cấp chức năng cho toàn bộ hệ sinh thái ClickHouse và thực hiện nhiệm vụ cần thiết trong Yandex.Cloud, chúng tôi quyết định đảm bảo rằng toàn bộ cộng đồng ClickHouse sẽ được hưởng lợi từ nó. Chúng tôi đã triển khai ClickHouse trên S3 chứ không phải ClickHouse trên MDS. Và đây là rất nhiều công việc.
Links:
"Lớp trừu tượng hệ thống tập tin"
"Tích hợp AWS SDK S3"
“Triển khai cơ sở giao diện IDisk cho S3”
"Tích hợp công cụ lưu trữ nhật ký với giao diện IDisk"
"Hỗ trợ công cụ nhật ký cho S3 và SeekableReadBuffer"
"Hỗ trợ lưu trữ Stripe Log S3"
"Storage MergeTree hỗ trợ ban đầu cho S3"
"MergeTree hỗ trợ đầy đủ cho S3"
"Hỗ trợ ReplicatedMergeTree trên S3"
“Thêm thông tin xác thực mặc định và tiêu đề tùy chỉnh cho bộ lưu trữ s3”
"S3 với cấu hình proxy động"
"S3 với trình phân giải proxy"
Đây là danh sách yêu cầu kéo để triển khai hệ thống tệp ảo trong ClickHouse. Đây là một số lượng lớn các yêu cầu kéo.
Links:
"Triển khai tối ưu liên kết cứng DiskS3"
“Máy khách HTTP S3 — Tránh sao chép luồng phản hồi vào bộ nhớ”
“Tránh sao chép toàn bộ luồng phản hồi vào bộ nhớ trong S3 HTTP
khách hàng"
“Khả năng lưu trữ các tập tin đánh dấu và lập chỉ mục cho đĩa S3”
"Di chuyển song song các phần từ DiskLocal sang DiskS3"
Nhưng công việc không kết thúc ở đó. Sau khi tính năng này được tạo, cần phải thực hiện thêm một số công việc để tối ưu hóa chức năng này.
Links:
"Thêm các sự kiện SelectedRows và SelectedBytes"
"Thêm sự kiện lập hồ sơ từ yêu cầu S3 vào system.events"
"Thêm QueryTimeMicroseconds, SelectQueryTimeMicroseconds và InsertQueryTimeMicroseconds"
Và sau đó cần phải làm cho nó có thể chẩn đoán được, thiết lập giám sát và làm cho nó có thể quản lý được.
Và tất cả những điều này được thực hiện để toàn bộ cộng đồng, toàn bộ hệ sinh thái ClickHouse, nhận được thành quả của công việc này.
Hãy chuyển sang cơ sở dữ liệu giao dịch, cơ sở dữ liệu OLTP, gần gũi hơn với cá nhân tôi.
Đây là bộ phận phát triển DBMS nguồn mở. Những kẻ này đang thực hiện phép thuật đường phố để cải thiện cơ sở dữ liệu mở mang tính giao dịch.
Một trong những dự án mà chúng tôi có thể sử dụng làm ví dụ để nói về cách thức và những gì chúng tôi làm, đó là Connection Pooler trong Postgres.
Postgres là một cơ sở dữ liệu quy trình. Điều này có nghĩa là cơ sở dữ liệu phải có càng ít kết nối mạng để xử lý các giao dịch càng tốt.
Mặt khác, trong môi trường đám mây, một tình huống điển hình là khi có hàng nghìn kết nối đến một cụm cùng một lúc. Và nhiệm vụ của người kết nối là đóng gói hàng nghìn kết nối vào một số lượng nhỏ kết nối máy chủ.
Chúng ta có thể nói rằng người kết nối tổng hợp là nhà điều hành điện thoại sắp xếp lại các byte để chúng tiếp cận cơ sở dữ liệu một cách hiệu quả.
Thật không may, không có từ tiếng Nga nào tốt cho người kết nối. Đôi khi nó được gọi là kết nối ghép kênh. Nếu bạn biết cách gọi người kết nối tổng hợp thì hãy nhớ cho tôi biết, tôi sẽ rất vui khi nói đúng ngôn ngữ kỹ thuật tiếng Nga.
Chúng tôi đã điều tra các trình tổng hợp kết nối phù hợp với cụm postgres được quản lý. Và PgBouncer là sự lựa chọn tốt nhất cho chúng tôi. Nhưng chúng tôi gặp phải một số vấn đề với PgBouncer. Nhiều năm trước, Volodya Borodin đã đưa ra báo cáo rằng chúng tôi sử dụng PgBouncer, chúng tôi thích mọi thứ, nhưng có những sắc thái, có điều gì đó cần phải làm.
Và chúng tôi đã làm việc. Chúng tôi đã khắc phục các sự cố gặp phải, vá Bouncer và cố gắng đẩy các yêu cầu kéo ngược dòng. Nhưng việc xử lý đơn luồng cơ bản rất khó khăn.
Chúng tôi phải thu thập các tầng từ Bouncers đã được vá. Khi chúng ta có nhiều Bouncers đơn luồng thì các kết nối ở lớp trên cùng sẽ được chuyển đến lớp Bouncers bên trong. Đây là một hệ thống được quản lý kém, khó xây dựng và mở rộng quy mô.
Chúng tôi đi đến kết luận rằng chúng tôi đã tạo ra công cụ tổng hợp kết nối của riêng mình, được gọi là Odyssey. Chúng tôi đã viết nó từ đầu.
Vào năm 2019, tại hội nghị PGCon, tôi đã giới thiệu công cụ tổng hợp này với cộng đồng nhà phát triển. Bây giờ chúng tôi có ít hơn 2 sao trên GitHub, tức là dự án vẫn còn tồn tại, dự án rất phổ biến.
Và nếu bạn tạo một cụm Postgres trong Yandex.Cloud, thì đó sẽ là một cụm có Odyssey tích hợp sẵn, được cấu hình lại khi chia tỷ lệ cụm qua lại.
Chúng ta đã học được gì từ dự án này? Khởi động một dự án cạnh tranh luôn là một bước đi tích cực, đó là một biện pháp cực đoan khi chúng ta nói rằng có những vấn đề không được giải quyết đủ nhanh, không được giải quyết trong khoảng thời gian phù hợp với chúng ta. Nhưng đây là một biện pháp hiệu quả.
PGBouncer bắt đầu phát triển nhanh hơn.
Và bây giờ các dự án khác đã xuất hiện. Ví dụ: pgagroal, được phát triển bởi các nhà phát triển Red Hat. Họ theo đuổi những mục tiêu giống nhau và thực hiện những ý tưởng giống nhau, nhưng tất nhiên có những chi tiết cụ thể của riêng họ, gần giống với các nhà phát triển pgagroal hơn.
Một trường hợp khác khi làm việc với cộng đồng postgres là khôi phục lại một thời điểm. Đây là quá trình khôi phục sau một lỗi, đây là quá trình khôi phục từ bản sao lưu.
Có rất nhiều bản sao lưu và chúng đều khác nhau. Hầu hết mọi nhà cung cấp Postgres đều có giải pháp sao lưu riêng.
Nếu bạn lấy tất cả các hệ thống dự phòng, tạo một ma trận đặc trưng và tính đùa định thức trong ma trận này thì nó sẽ bằng XNUMX. Điều đó có nghĩa là gì? Điều gì sẽ xảy ra nếu bạn lấy một tệp sao lưu cụ thể, thì nó không thể được tập hợp từ các phần của tất cả các tệp khác. Nó độc đáo trong cách thực hiện, nó độc đáo trong mục đích, nó độc đáo trong những ý tưởng được lồng ghép trong đó. Và tất cả đều cụ thể.
Trong khi chúng tôi đang giải quyết vấn đề này, CitusData đã khởi động dự án WAL-G. Đây là một hệ thống sao lưu được tạo ra với mục đích hướng tới môi trường đám mây. Bây giờ CitusData đã là một phần của Microsoft. Và tại thời điểm đó, chúng tôi thực sự thích những ý tưởng được đưa ra trong các phiên bản đầu tiên của WAL-G. Và chúng tôi bắt đầu đóng góp cho dự án này.
Hiện có hàng chục nhà phát triển trong dự án này, nhưng 10 nhà đóng góp hàng đầu cho WAL-G bao gồm 6 Yandexoids. Chúng tôi đã mang rất nhiều ý tưởng của mình đến đó. Và, tất nhiên, chúng tôi đã tự mình triển khai, tự kiểm tra, tự đưa chúng vào sản xuất, chúng tôi tự mình sử dụng chúng, tự mình tìm ra nơi cần chuyển tiếp, đồng thời tương tác với cộng đồng WAL-G rộng lớn.
Và theo quan điểm của chúng tôi, giờ đây hệ thống sao lưu này, bao gồm cả những nỗ lực của chúng tôi, đã trở nên tối ưu cho môi trường đám mây. Đây là chi phí tốt nhất để sao lưu Postgres trên đám mây.
Nó có nghĩa là gì? Chúng tôi đang thúc đẩy một ý tưởng khá lớn: việc sao lưu phải an toàn, chi phí vận hành rẻ và khôi phục nhanh nhất có thể.
Tại sao nó phải rẻ để vận hành? Khi không có gì bị hỏng, bạn không nên biết mình có bản sao lưu. Mọi thứ đều hoạt động tốt, bạn lãng phí ít CPU nhất có thể, sử dụng ít tài nguyên đĩa nhất có thể và gửi càng ít byte vào mạng càng tốt để không ảnh hưởng đến tải trọng của các dịch vụ có giá trị của bạn.
Và khi mọi thứ bị hỏng, chẳng hạn như quản trị viên đánh rơi dữ liệu, có sự cố xảy ra và bạn cần quay lại quá khứ gấp, bạn lấy lại toàn bộ số tiền, vì bạn muốn dữ liệu của mình trở lại nhanh chóng và nguyên vẹn.
Và chúng tôi đã thúc đẩy ý tưởng đơn giản này. Và đối với chúng tôi, có vẻ như chúng tôi đã thành công trong việc thực hiện được nó.
Nhưng đó không phải là tất cả. Chúng tôi muốn một điều nhỏ nữa. Chúng tôi muốn có nhiều cơ sở dữ liệu khác nhau. Không phải tất cả khách hàng của chúng tôi đều sử dụng Postgres. Một số người sử dụng MySQL, MongoDB. Trong cộng đồng, các nhà phát triển khác đã hỗ trợ FoundationDB. Và danh sách này không ngừng mở rộng.
Cộng đồng thích ý tưởng cơ sở dữ liệu được chạy trong môi trường được quản lý trên đám mây. Và các nhà phát triển duy trì cơ sở dữ liệu của họ, cơ sở dữ liệu này có thể được sao lưu thống nhất cùng với Postgres bằng hệ thống sao lưu của chúng tôi.
Chúng ta học được gì từ câu chuyện này? Sản phẩm của chúng tôi, với tư cách là một bộ phận phát triển, không phải là dòng mã, không phải câu lệnh, không phải tệp. Sản phẩm của chúng tôi không phải là yêu cầu kéo. Đây là những ý tưởng mà chúng tôi truyền tải tới cộng đồng. Đây là chuyên môn công nghệ và sự chuyển động của công nghệ hướng tới môi trường đám mây.
Có một cơ sở dữ liệu như Postgres. Tôi thích lõi Postgres nhất. Tôi dành nhiều thời gian để phát triển cốt lõi của Postgres cùng cộng đồng.
Nhưng ở đây phải nói rằng Yandex.Cloud có bản cài đặt nội bộ các cơ sở dữ liệu được quản lý. Và nó đã bắt đầu từ lâu trong Yandex.Mail. Kiến thức chuyên môn hiện đã giúp Postgres được quản lý đã được tích lũy khi thư muốn chuyển vào Postgres.
Thư có những yêu cầu rất giống với đám mây. Nó cần bạn có khả năng mở rộng quy mô để tăng trưởng theo cấp số nhân bất ngờ tại bất kỳ điểm nào trong dữ liệu của bạn. Và thư đã có tải hàng trăm triệu hộp thư của một số lượng lớn người dùng liên tục đưa ra nhiều yêu cầu.
Và đây là một thách thức khá nghiêm trọng đối với nhóm đang phát triển Postgres. Hồi đó, bất kỳ vấn đề nào chúng tôi gặp phải đều được báo cáo cho cộng đồng. Và những vấn đề này đã được cộng đồng khắc phục và sửa chữa ở một số nơi thậm chí ở mức hỗ trợ trả phí cho một số cơ sở dữ liệu khác và thậm chí tốt hơn. Tức là bạn có thể gửi thư cho hacker PGSQL và nhận được phản hồi trong vòng 40 phút. Hỗ trợ trả phí trong một số cơ sở dữ liệu có thể cho rằng có nhiều thứ được ưu tiên hơn lỗi của bạn.
Bây giờ cài đặt nội bộ của Postgres có dung lượng vài petabyte dữ liệu. Đây là vài triệu yêu cầu mỗi giây. Đây là hàng ngàn cụm. Nó có quy mô rất lớn.
Nhưng có một sắc thái. Nó không tồn tại trên các ổ đĩa mạng ưa thích mà trên phần cứng khá đơn giản. Và có một môi trường thử nghiệm dành riêng cho những điều mới mẻ thú vị.
Và tại một thời điểm nhất định trong môi trường thử nghiệm, chúng tôi nhận được một thông báo cho biết rằng các bất biến nội bộ của các chỉ mục cơ sở dữ liệu đã bị vi phạm.
Bất biến là một loại mối quan hệ mà chúng ta mong đợi sẽ luôn được giữ vững.
Một tình huống rất nguy kịch đối với chúng tôi. Nó chỉ ra rằng một số dữ liệu có thể đã bị mất. Và mất dữ liệu là một điều hết sức thảm khốc.
Ý tưởng chung mà chúng tôi tuân theo trong cơ sở dữ liệu được quản lý là ngay cả khi nỗ lực thì cũng khó có thể mất dữ liệu. Ngay cả khi bạn cố tình loại bỏ chúng, bạn vẫn sẽ cần phải bỏ qua sự vắng mặt của chúng trong một thời gian dài. Bảo mật dữ liệu là một tôn giáo mà chúng tôi tuân theo khá chăm chỉ.
Và ở đây nảy sinh một tình huống gợi ý rằng có thể có một tình huống mà chúng ta có thể không chuẩn bị sẵn sàng. Và chúng tôi bắt đầu chuẩn bị cho tình huống này.
Điều đầu tiên chúng tôi làm là chôn các khúc gỗ từ hàng nghìn cụm này. Chúng tôi đã tìm thấy cụm nào nằm trên các đĩa có chương trình cơ sở có vấn đề đang làm mất các bản cập nhật trang dữ liệu. Đã đánh dấu tất cả mã dữ liệu Postgres. Và chúng tôi đã đánh dấu những thông báo cho thấy hành vi vi phạm các bất biến nội bộ bằng mã được thiết kế để phát hiện lỗi dữ liệu.
Bản vá này thực tế đã được cộng đồng chấp nhận mà không cần thảo luận nhiều, vì trong từng trường hợp cụ thể, rõ ràng đã có điều gì đó tồi tệ xảy ra và cần phải được báo cáo vào nhật ký.
Sau đó, chúng tôi đã đạt đến mức chúng tôi phải theo dõi nhật ký quét. Và trong trường hợp có tin nhắn đáng ngờ, anh ta đánh thức nhân viên trực và nhân viên trực sẽ sửa chữa nó.
Nhưng! Quét nhật ký là một hoạt động rẻ tiền trên một cụm và cực kỳ tốn kém đối với một nghìn cụm.
Chúng tôi đã viết một phần mở rộng có tên . Nó tạo ra một cái nhìn về cơ sở dữ liệu trong đó bạn có thể chọn số liệu thống kê về các lỗi trong quá khứ một cách rẻ tiền và nhanh chóng. Và nếu chúng ta cần đánh thức nhân viên trực, thì chúng ta sẽ tìm hiểu về điều này mà không cần quét các tệp gigabyte mà bằng cách trích xuất một vài byte từ bảng băm.
Tiện ích mở rộng này đã được thông qua, ví dụ, trong kho lưu trữ dành cho . Nếu bạn muốn sử dụng nó, bạn có thể tự cài đặt nó. Tất nhiên đó là nguồn mở.
Nhưng đó không phải là tất cả. Chúng tôi bắt đầu sử dụng Amcheck, một tiện ích mở rộng do cộng đồng xây dựng, để tìm các vi phạm bất biến trong chỉ mục.
Và chúng tôi phát hiện ra rằng nếu bạn vận hành nó trên quy mô lớn thì sẽ có lỗi. Chúng tôi bắt đầu sửa chúng. Sự điều chỉnh của chúng tôi đã được chấp nhận.
Chúng tôi phát hiện ra rằng tiện ích mở rộng này không thể phân tích chỉ mục GiST & GIT. Chúng tôi đã làm cho họ hỗ trợ. Nhưng sự hỗ trợ này vẫn đang được cộng đồng thảo luận vì đây là một chức năng tương đối mới và có rất nhiều chi tiết ở đó.
Và chúng tôi cũng phát hiện ra rằng khi kiểm tra các chỉ mục vi phạm trên người đứng đầu sao chép, trên bản gốc, mọi thứ đều hoạt động tốt, nhưng trên các bản sao, trên người theo dõi, việc tìm kiếm tham nhũng không hiệu quả lắm. Không phải tất cả các bất biến đều được kiểm tra. Và một bất biến đã làm phiền chúng tôi rất nhiều. Và chúng tôi đã dành một năm rưỡi để liên lạc với cộng đồng để kích hoạt tính năng kiểm tra bản sao này.
Chúng tôi đã viết mã phải tuân theo tất cả các... giao thức có thể. Chúng tôi đã thảo luận về bản vá này khá lâu với Peter Gaghan từ Crunchy Data. Anh ấy đã phải sửa đổi một chút cây B hiện có trong Postgres để chấp nhận bản vá này. Anh ấy đã được chấp nhận. Và hiện nay việc kiểm tra chỉ mục trên các bản sao cũng đã trở nên đủ hiệu quả để phát hiện những vi phạm mà chúng tôi gặp phải. Nghĩa là, đây là những vi phạm có thể do lỗi trong phần sụn đĩa, lỗi trong Postgres, lỗi trong nhân Linux và các sự cố phần cứng. Một danh sách khá phong phú các nguồn gốc của vấn đề mà chúng tôi đang chuẩn bị.
Nhưng bên cạnh các chỉ mục, còn có một phần như heap, tức là nơi lưu trữ dữ liệu. Và không có nhiều bất biến có thể kiểm tra được.
Chúng tôi có tiện ích mở rộng có tên Heapcheck. Chúng tôi bắt đầu phát triển nó. Và song song đó, cùng với chúng tôi, công ty EnterpriseDB cũng bắt đầu viết một module mà họ gọi là Heapcheck theo cách tương tự. Chỉ có chúng tôi gọi nó là PGHeapcheck, và họ chỉ gọi nó là Heapcheck. Họ có nó với các chức năng tương tự, chữ ký hơi khác một chút, nhưng có cùng ý tưởng. Họ đã thực hiện chúng tốt hơn một chút ở một số nơi. Và họ đã đăng nó ở dạng nguồn mở trước đây.
Và bây giờ chúng tôi đang phát triển sự mở rộng của họ, bởi vì đó không còn là sự mở rộng của họ nữa mà là sự mở rộng của cộng đồng. Và trong tương lai, đây là một phần kernel sẽ được cung cấp cho mọi người để họ có thể biết trước những vấn đề trong tương lai.
Ở một số nơi, chúng tôi thậm chí còn đi đến kết luận rằng chúng tôi có kết quả dương tính giả trong hệ thống giám sát của mình. Ví dụ: hệ thống 1C. Khi sử dụng cơ sở dữ liệu, Postgres đôi khi ghi dữ liệu vào đó để nó có thể đọc được, nhưng pg_dump thì không thể đọc được.
Tình huống này trông giống như sự hỏng hóc đối với hệ thống phát hiện vấn đề của chúng tôi. Người sĩ quan trực ban đã thức dậy. Người sĩ quan trực ban nhìn vào những gì đang xảy ra. Sau một thời gian, một khách hàng đến và nói rằng tôi có vấn đề. Người phục vụ giải thích vấn đề là gì. Nhưng vấn đề nằm ở lõi Postgres.
Tôi tìm thấy một cuộc thảo luận về tính năng này. Và anh ấy viết rằng chúng tôi đã gặp phải tính năng này và thật khó chịu, một người thức dậy vào ban đêm để tìm hiểu xem nó là gì.
Cộng đồng trả lời: “Ồ, chúng tôi thực sự cần phải sửa nó”.
Tôi có một sự tương tự đơn giản. Nếu bạn đang đi trong một chiếc giày có hạt cát trong đó, thì về nguyên tắc, bạn có thể đi tiếp - không vấn đề gì. Nếu bạn bán bốt cho hàng nghìn người thì hãy làm những đôi bốt không có cát. Và nếu một trong những người dùng giày của bạn sắp chạy marathon thì bạn muốn tạo ra những đôi giày thật tốt rồi mở rộng quy mô cho tất cả người dùng của mình. Và những người dùng bất ngờ như vậy luôn ở trong môi trường đám mây. Luôn có những người dùng khai thác cụm theo một cách nguyên bản nào đó. Bạn phải luôn chuẩn bị cho việc này.
Chúng ta đã học được gì ở đây? Chúng tôi đã học được một điều đơn giản: điều quan trọng nhất là giải thích cho cộng đồng rằng có vấn đề. Nếu cộng đồng đã nhận ra vấn đề thì sự cạnh tranh tự nhiên sẽ nảy sinh để giải quyết vấn đề. Bởi vì mọi người đều muốn giải quyết một vấn đề quan trọng. Tất cả các nhà cung cấp, tất cả các hacker đều hiểu rằng bản thân họ có thể dẫm lên cái cào này nên muốn loại bỏ chúng.
Nếu bạn đang giải quyết một vấn đề, nhưng điều đó không làm phiền ai ngoài bạn, nhưng bạn giải quyết nó một cách có hệ thống và cuối cùng nó được coi là một vấn đề, thì yêu cầu kéo của bạn chắc chắn sẽ được chấp nhận. Bản vá của bạn sẽ được chấp nhận, các cải tiến của bạn hoặc thậm chí các yêu cầu cải tiến sẽ được cộng đồng xem xét. Vào cuối ngày, chúng tôi làm cho cơ sở dữ liệu trở nên tốt hơn cho nhau.
Một cơ sở dữ liệu thú vị là Greenplum. Đó là một cơ sở dữ liệu song song cao dựa trên cơ sở mã Postgres mà tôi rất quen thuộc.
Và Greenplum có chức năng thú vị - nối thêm các bảng được tối ưu hóa. Đây là những bảng mà bạn có thể nhanh chóng thêm vào. Chúng có thể là cột hoặc hàng.
Nhưng không có phân cụm, tức là không có chức năng để bạn có thể sắp xếp dữ liệu trong bảng theo thứ tự của một trong các chỉ mục.
Những người trên taxi đến gặp tôi và nói: “Andrey, anh biết Postgres. Và ở đây nó gần như giống nhau. Chuyển sang 20 phút. Bạn hãy lấy nó và làm nó.” Tôi nghĩ rằng có, tôi biết Postgres, chuyển đổi trong 20 phút - tôi cần thực hiện việc này.
Nhưng không, không phải 20 phút đâu, tôi đã viết nó suốt nhiều tháng trời. Tại hội nghị PgConf.Nga, tôi đã tiếp cận Heikki Linakangas từ Pivotal và hỏi: “Có vấn đề gì với việc này không? Tại sao không có cụm bảng được tối ưu hóa bổ sung?” Anh ấy nói: “Bạn lấy dữ liệu. Bạn sắp xếp, bạn sắp xếp lại. Đó chỉ là một công việc thôi." Tôi: “Ồ, vâng, bạn chỉ cần cầm lấy và làm thôi.” Anh ấy nói: “Đúng, chúng tôi cần rảnh tay để làm việc này.” Tôi nghĩ rằng tôi chắc chắn cần phải làm điều này.
Và vài tháng sau, tôi đã gửi một yêu cầu kéo để triển khai chức năng này. Yêu cầu kéo này đã được Pivotal cùng với cộng đồng xem xét. Tất nhiên, đã có lỗi.
Nhưng điều thú vị nhất là khi pull request này được hợp nhất, các lỗi đã được tìm thấy ngay trong Greenplum. Chúng tôi nhận thấy rằng các bảng heap đôi khi phá vỡ tính giao dịch khi được phân cụm. Và đây là điều cần phải khắc phục. Và cô ấy đang ở chỗ tôi vừa chạm vào. Và phản ứng tự nhiên của tôi là – được rồi, hãy để tôi làm điều này nữa.
Tôi đã sửa lỗi này. Đã gửi yêu cầu kéo tới người sửa lỗi. Anh ấy đã bị giết.
Sau đó, hóa ra chức năng này cần phải có trong phiên bản Greenplum dành cho PostgreSQL 12. Tức là, cuộc phiêu lưu kéo dài 20 phút tiếp tục với những cuộc phiêu lưu thú vị mới. Thật thú vị khi chạm vào sự phát triển hiện tại, nơi cộng đồng đang tạo ra các tính năng mới và quan trọng nhất. Nó bị đóng băng.
Nhưng nó không kết thúc ở đó. Sau tất cả, hóa ra chúng tôi cần phải viết tài liệu cho tất cả những điều này.
Tôi bắt đầu viết tài liệu. May mắn thay, những người làm phim tài liệu từ Pivotal đã xuất hiện. Tiếng Anh là ngôn ngữ mẹ đẻ của họ. Họ đã giúp tôi với các tài liệu. Trên thực tế, chính họ đã viết lại những gì tôi đề xuất thành tiếng Anh thực sự.
Và ở đây, có vẻ như cuộc phiêu lưu đã kết thúc. Và bạn có biết chuyện gì đã xảy ra sau đó không? Những người trên taxi đến gặp tôi và nói: “Vẫn còn hai cuộc phiêu lưu, mỗi cuộc kéo dài 10 phút”. Và tôi nên nói gì với họ? Tôi đã nói rằng bây giờ tôi sẽ đưa ra một báo cáo quy mô, sau đó chúng ta sẽ xem những cuộc phiêu lưu của bạn, vì đây là một công việc thú vị.
Chúng ta học được gì từ trường hợp này? Bởi vì làm việc với nguồn mở là luôn làm việc với một người cụ thể, luôn là làm việc với cộng đồng. Bởi vì ở mỗi giai đoạn tôi đều làm việc với một số nhà phát triển, một số người thử nghiệm, một số hacker, một số nhà tài liệu, một số kiến trúc sư. Tôi không làm việc với Greenplum, tôi làm việc với những người xung quanh Greenplum.
Nhưng! Có một điểm quan trọng khác - đó chỉ là công việc. Tức là bạn đến, uống cà phê, viết code. Tất cả các loại bất biến đơn giản đều hoạt động. Làm bình thường - sẽ ổn thôi! Và đó là một công việc khá thú vị. Có yêu cầu cho công việc này từ các khách hàng Yandex.Cloud, người dùng cụm của chúng tôi cả bên trong Yandex và bên ngoài. Và tôi nghĩ rằng số lượng dự án mà chúng tôi tham gia sẽ tăng lên và mức độ tham gia của chúng tôi cũng sẽ tăng lên.
Đó là tất cả. Hãy chuyển sang các câu hỏi.
Phiên hỏi đáp
Xin chào! Chúng ta có một phiên hỏi đáp khác. Và trong studio Andrei Borodin. Đây là người vừa nói với bạn về sự đóng góp của Yandex.Cloud và Yandex cho nguồn mở. Báo cáo của chúng tôi bây giờ không hoàn toàn là về Đám mây mà đồng thời chúng tôi cũng dựa trên những công nghệ như vậy. Nếu không có những gì bạn đã làm trong Yandex thì sẽ không có dịch vụ nào trong Yandex.Cloud, vì vậy cá nhân tôi xin cảm ơn bạn. Và câu hỏi đầu tiên trong buổi phát sóng: “Mỗi dự án mà bạn đề cập đã viết về là gì?”
Hệ thống sao lưu trong WAL-G được viết bằng Go. Đây là một trong những dự án mới hơn mà chúng tôi đã thực hiện. Anh ấy thực sự chỉ mới 3 tuổi. Và cơ sở dữ liệu thường liên quan đến độ tin cậy. Và điều này có nghĩa là cơ sở dữ liệu khá cũ và chúng thường được viết bằng C. Dự án Postgres đã bắt đầu khoảng 30 năm trước. Khi đó C89 là sự lựa chọn đúng đắn. Và Postgres được viết trên đó. Cơ sở dữ liệu hiện đại hơn như ClickHouse thường được viết bằng C++. Tất cả sự phát triển hệ thống đều dựa trên C và C++.
Câu hỏi từ người quản lý tài chính của chúng tôi, người chịu trách nhiệm về chi phí tại Cloud: “Tại sao Cloud lại chi tiền để hỗ trợ nguồn mở?”
Có một câu trả lời đơn giản cho người quản lý tài chính ở đây. Chúng tôi làm điều này để làm cho dịch vụ của chúng tôi tốt hơn. Chúng ta có thể làm tốt hơn ở những mặt nào? Chúng ta có thể làm mọi việc hiệu quả hơn, nhanh hơn và khiến mọi thứ có khả năng mở rộng hơn. Nhưng đối với chúng tôi, câu chuyện này chủ yếu là về độ tin cậy. Ví dụ: trong một hệ thống sao lưu, chúng tôi xem xét 100% các bản vá áp dụng cho nó. Chúng tôi biết mật mã là gì. Và chúng tôi cảm thấy thoải mái hơn khi đưa các phiên bản mới vào sản xuất. Tức là trước hết đó là về sự tự tin, về sự sẵn sàng phát triển và về độ tin cậy
Một câu hỏi khác: “Các yêu cầu của người dùng bên ngoài sống trong Yandex.Cloud có khác với người dùng nội bộ sống trong Đám mây nội bộ không?”
Tất nhiên, cấu hình tải là khác nhau. Nhưng theo quan điểm của bộ phận tôi, tất cả các trường hợp đặc biệt và thú vị đều được tạo ra trên một tải không chuẩn. Những nhà phát triển có trí tưởng tượng, những nhà phát triển làm được những điều không ngờ tới, có nhiều khả năng được tìm thấy cả trong nội bộ lẫn bên ngoài. Về vấn đề này, tất cả chúng ta đều giống nhau. Và, có lẽ, tính năng quan trọng duy nhất bên trong hoạt động của cơ sở dữ liệu Yandex là bên trong Yandex chúng ta có một bài giảng. Tại một thời điểm nào đó, một số vùng khả dụng hoàn toàn chìm trong bóng tối và tất cả các dịch vụ Yandex bằng cách nào đó phải tiếp tục hoạt động bất chấp điều này. Đây là một sự khác biệt nhỏ. Nhưng nó tạo ra rất nhiều nghiên cứu phát triển ở giao diện của cơ sở dữ liệu và ngăn xếp mạng. Mặt khác, các cài đặt bên ngoài và bên trong sẽ tạo ra các yêu cầu giống nhau về tính năng và các yêu cầu tương tự để cải thiện độ tin cậy và hiệu suất.
Câu hỏi tiếp theo: “Cá nhân bạn cảm thấy thế nào về thực tế là phần lớn những gì bạn làm đều được các Đám mây khác sử dụng?” Chúng tôi sẽ không nêu tên những dự án cụ thể nhưng nhiều dự án được thực hiện trong Yandex.Cloud được sử dụng trên đám mây của người khác.
Điều này thật tuyệt. Đầu tiên, đó là dấu hiệu cho thấy chúng ta đã làm điều gì đó đúng đắn. Và nó làm trầy xước cái tôi. Và chúng tôi càng tin tưởng rằng mình đã đưa ra quyết định đúng đắn. Mặt khác, đây là niềm hy vọng rằng trong tương lai điều này sẽ mang đến cho chúng ta những ý tưởng mới, những yêu cầu mới từ người dùng bên thứ ba. Hầu hết các vấn đề trên GitHub đều do quản trị viên hệ thống cá nhân, DBA cá nhân, kiến trúc sư cá nhân, kỹ sư cá nhân tạo ra, nhưng đôi khi những người có kinh nghiệm hệ thống đến và nói rằng trong 30% một số trường hợp nhất định, chúng tôi gặp phải vấn đề này và hãy nghĩ cách giải quyết nó. Đây là điều chúng tôi mong chờ nhất. Chúng tôi mong muốn được chia sẻ kinh nghiệm với các nền tảng đám mây khác.
Bạn đã nói rất nhiều về cuộc chạy marathon. Tôi biết bạn đã chạy marathon ở Moscow. Kết quả là? Vượt qua những người từ PostgreSQL?
Không, Oleg Bartunov chạy rất nhanh. Anh ấy đã hoàn thành trước tôi một giờ. Nhìn chung, tôi hài lòng với quãng đường mình đã đạt được. Đối với tôi, chỉ cần về đích đã là thành tựu. Nhìn chung, thật đáng ngạc nhiên khi có rất nhiều người chạy trong cộng đồng postgres. Đối với tôi, dường như có một mối quan hệ nào đó giữa các môn thể thao aerobic và mong muốn lập trình hệ thống.
Ý bạn là không có người chạy nào ở ClickHouse?
Tôi biết chắc chắn rằng họ đang ở đó. ClickHouse cũng là một cơ sở dữ liệu. Nhân tiện, Oleg hiện đang viết thư cho tôi: “Chúng ta có nên chạy theo bản báo cáo không?” Ý kiến hay.
Một câu hỏi khác từ buổi phát sóng từ Nikita: “Tại sao bạn lại tự mình sửa lỗi ở Greenplum mà không đưa nó cho đàn em?” Đúng, không rõ lỗi là gì và ở dịch vụ nào, nhưng nó có thể là lỗi mà bạn đã nói đến.
Vâng, về nguyên tắc, nó có thể đã được trao cho ai đó. Đó chỉ là mã mà tôi vừa thay đổi. Và việc tiếp tục làm việc đó là điều đương nhiên. Về nguyên tắc, ý tưởng chia sẻ kiến thức chuyên môn với nhóm là một ý tưởng hay. Chúng tôi chắc chắn sẽ chia sẻ nhiệm vụ Greenplum giữa tất cả các thành viên trong bộ phận của chúng tôi.
Vì chúng ta đang nói về đàn em nên đây là một câu hỏi. Người đó quyết định tạo cam kết đầu tiên trong Postgres. Anh ta cần làm gì để thực hiện cam kết đầu tiên?
Đây là một câu hỏi thú vị: “Bắt đầu từ đâu?” Thông thường, việc bắt đầu với thứ gì đó trong kernel thường khá khó khăn. Ví dụ, trong Postgres, có một danh sách việc cần làm. Nhưng trên thực tế, đây là bản ghi lại những gì họ đã cố gắng làm nhưng không thành công. Đây là những điều phức tạp. Và thông thường bạn có thể tìm thấy một số tiện ích trong hệ sinh thái, một số tiện ích mở rộng có thể được cải thiện, thu hút ít sự chú ý hơn từ các nhà phát triển kernel. Và theo đó, có nhiều điểm phát triển hơn ở đó. Tại chương trình viết mã Mùa hè của Google, hàng năm cộng đồng postgres đưa ra nhiều chủ đề khác nhau có thể được giải quyết. Tôi nghĩ năm nay chúng tôi có ba học sinh. Một người thậm chí còn viết bằng WAL-G về các chủ đề quan trọng đối với Yandex. Trong Greenplum, mọi thứ đơn giản hơn trong cộng đồng Postgres, vì hacker Greenplum xử lý các pull request rất tốt và bắt đầu xem xét ngay lập tức. Gửi bản vá tới Postgres mất vài tháng, nhưng Greenplum sẽ đến sau một ngày và xem bạn đã làm gì. Một điều nữa là Greenplum cần giải quyết những vấn đề hiện tại. Greenplum không được sử dụng rộng rãi nên việc tìm ra vấn đề của bạn khá khó khăn. Và tất nhiên trước hết chúng ta cần giải quyết vấn đề.
Nguồn: www.habr.com