Người máy DBA Joe. Anatoly Stansler (Postgres.ai)

Làm thế nào để một nhà phát triển phụ trợ hiểu rằng một truy vấn SQL sẽ hoạt động tốt trên một “sản phẩm”? Trong các công ty lớn hoặc đang phát triển nhanh chóng, không phải ai cũng có quyền truy cập vào "sản phẩm". Và với quyền truy cập, không phải tất cả các yêu cầu đều có thể được kiểm tra dễ dàng và việc tạo một bản sao của cơ sở dữ liệu thường mất hàng giờ. Để giải quyết những vấn đề này, chúng tôi đã tạo ra một DBA nhân tạo - Joe. Nó đã được triển khai thành công ở một số công ty và giúp ích cho hơn một chục nhà phát triển.

Video:

Chào mọi người! Tên tôi là Anatoly Stansler. Tôi làm việc cho một công ty postgres.ai. Chúng tôi cam kết đẩy nhanh quá trình phát triển bằng cách loại bỏ sự chậm trễ liên quan đến công việc của Postgres từ các nhà phát triển, DBA và QA.

Chúng tôi có những khách hàng tuyệt vời và hôm nay một phần của báo cáo sẽ được dành cho những trường hợp mà chúng tôi đã gặp khi làm việc với họ. Tôi sẽ nói về cách chúng tôi đã giúp họ giải quyết những vấn đề khá nghiêm trọng.

Khi chúng tôi đang phát triển và thực hiện các quá trình di chuyển tải trọng cao phức tạp, chúng tôi tự đặt câu hỏi: “Liệu quá trình di chuyển này có thành công không?”. Chúng tôi sử dụng đánh giá, chúng tôi sử dụng kiến ​​​​thức của các đồng nghiệp có kinh nghiệm hơn, các chuyên gia DBA. Và họ có thể biết liệu nó có bay hay không.

Nhưng có lẽ sẽ tốt hơn nếu chúng tôi có thể tự kiểm tra nó trên các bản sao có kích thước đầy đủ. Và hôm nay chúng ta sẽ chỉ nói về những cách tiếp cận để thử nghiệm hiện nay và cách nó có thể được thực hiện tốt hơn và bằng những công cụ nào. Chúng tôi cũng sẽ nói về những ưu và nhược điểm của những cách tiếp cận như vậy và những gì chúng tôi có thể khắc phục ở đây.

Ai đã từng lập chỉ mục trực tiếp trên sản phẩm hoặc thực hiện bất kỳ thay đổi nào? Một ít của. Và tại sao điều này lại dẫn đến việc dữ liệu bị mất hoặc thời gian ngừng hoạt động? Rồi bạn biết nỗi đau này. Cảm ơn Chúa có bản sao lưu.

Cách tiếp cận đầu tiên là thử nghiệm trong sản phẩm. Hoặc, khi nhà phát triển ngồi trên máy cục bộ, anh ta có dữ liệu thử nghiệm, có một số loại lựa chọn hạn chế. Và chúng tôi tung ra sản phẩm, và chúng tôi gặp tình huống này.

Nó đau, nó đắt. Có lẽ tốt nhất là không nên.

Và cách tốt nhất để làm điều đó là gì?

Hãy dàn dựng và chọn một số phần của prod ở đó. Hoặc tốt nhất, hãy lấy một sản phẩm thực sự, tất cả dữ liệu. Và sau khi chúng tôi đã phát triển nó cục bộ, chúng tôi sẽ kiểm tra thêm về dàn dựng.

Điều này sẽ cho phép chúng tôi loại bỏ một số lỗi, tức là ngăn không cho chúng xuất hiện trên sản phẩm.

Vấn đề là gì?

• Vấn đề là chúng tôi chia sẻ dàn dựng này với các đồng nghiệp. Và rất thường xuyên xảy ra trường hợp bạn thực hiện một số thay đổi nào đó, bam - và không có dữ liệu, công việc đổ bể. Dàn dựng là nhiều terabyte. Và bạn phải đợi rất lâu để nó tăng trở lại. Và chúng tôi quyết định hoàn thành nó vào ngày mai. Thế là xong, chúng ta có một bước phát triển.
• Và, tất nhiên, chúng tôi có nhiều đồng nghiệp làm việc ở đó, nhiều nhóm. Và nó phải được thực hiện thủ công. Và điều này thật bất tiện.

Và điều đáng nói là chúng ta chỉ có một lần thử, một lần chụp, nếu chúng ta muốn thực hiện một số thay đổi đối với cơ sở dữ liệu, chạm vào dữ liệu, thay đổi cấu trúc. Và nếu có sự cố xảy ra, nếu có lỗi trong quá trình di chuyển, thì chúng tôi sẽ không nhanh chóng quay lại.

Cách này tốt hơn cách tiếp cận trước đây, nhưng vẫn có khả năng cao là một số loại lỗi sẽ xảy ra trong quá trình sản xuất.

Điều gì ngăn cản chúng tôi cung cấp cho mỗi nhà phát triển một băng thử nghiệm, một bản sao có kích thước đầy đủ? Tôi nghĩ rằng rõ ràng những gì cản trở.

Ai có cơ sở dữ liệu lớn hơn một terabyte? Hơn nửa căn phòng.

Và rõ ràng là việc giữ máy cho từng nhà phát triển khi có một lượng sản xuất lớn như vậy là rất tốn kém, bên cạnh đó còn mất nhiều thời gian.

Chúng tôi có những khách hàng đã nhận ra rằng việc kiểm tra tất cả các thay đổi trên các bản sao có kích thước đầy đủ là rất quan trọng, nhưng cơ sở dữ liệu của họ nhỏ hơn một terabyte và không có tài nguyên để giữ băng ghế thử nghiệm cho mỗi nhà phát triển. Do đó, họ phải tải các bãi chứa cục bộ về máy của mình và kiểm tra theo cách này. Mất nhiều thời gian.

Ngay cả khi bạn làm điều đó bên trong cơ sở hạ tầng, thì việc tải xuống một terabyte dữ liệu mỗi giờ đã là rất tốt. Nhưng họ sử dụng các bãi chứa hợp lý, họ tải xuống cục bộ từ đám mây. Đối với họ, tốc độ là khoảng 200 gigabyte mỗi giờ. Và vẫn cần thời gian để quay lại từ kết xuất hợp lý, cuộn lên các chỉ mục, v.v.

Nhưng họ sử dụng phương pháp này vì nó cho phép họ giữ sản phẩm đáng tin cậy.

Chúng ta có thể làm gì ở đây? Hãy làm cho băng ghế thử nghiệm trở nên rẻ và cung cấp cho mỗi nhà phát triển băng ghế thử nghiệm của riêng họ.

Và điều này là có thể.

Và theo cách tiếp cận này, khi chúng tôi tạo các bản sao mỏng cho mỗi nhà phát triển, chúng tôi có thể chia sẻ nó trên một máy. Ví dụ: nếu bạn có cơ sở dữ liệu 10TB và muốn cung cấp cho 10 nhà phát triển, bạn không cần phải có cơ sở dữ liệu XNUMX x XNUMXTB. Bạn chỉ cần một máy để tạo các bản sao mỏng riêng biệt cho mỗi nhà phát triển sử dụng một máy. Tôi sẽ cho bạn biết làm thế nào nó hoạt động một lát sau.

Ví dụ thực tế:

• DB - 4,5 terabyte.

• Chúng tôi có thể nhận được các bản sao độc lập trong 30 giây.

Bạn không cần phải đợi đứng thử và phụ thuộc vào mức độ lớn nhỏ của nó. Bạn có thể nhận được nó trong vài giây. Đó sẽ là những môi trường hoàn toàn biệt lập, nhưng chia sẻ dữ liệu với nhau.

Điều đó thật tuyệt. Ở đây chúng ta đang nói về phép thuật và một vũ trụ song song.

Trong trường hợp của chúng tôi, điều này hoạt động bằng cách sử dụng hệ thống OpenZFS.

OpenZFS là một hệ thống tệp sao chép khi ghi hỗ trợ ảnh chụp nhanh và sao chép ngay lập tức. Nó đáng tin cậy và có thể mở rộng. Cô ấy rất dễ quản lý. Nó thực sự có thể được triển khai trong hai đội.

Có những lựa chọn khác:

• lvm,

• Lưu trữ (ví dụ: Lưu trữ thuần túy).

Phòng thí nghiệm cơ sở dữ liệu mà tôi đang nói đến là mô-đun. Có thể được thực hiện bằng cách sử dụng các tùy chọn này. Nhưng hiện tại, chúng tôi tập trung vào OpenZFS, vì có vấn đề cụ thể với LVM.

Làm thế nào nó hoạt động? Thay vì ghi đè dữ liệu mỗi khi thay đổi, chúng tôi lưu dữ liệu đó bằng cách đánh dấu đơn giản rằng dữ liệu mới này đến từ một thời điểm mới, một ảnh chụp nhanh mới.

Và trong tương lai, khi chúng tôi muốn khôi phục hoặc muốn tạo một bản sao mới từ một số phiên bản cũ hơn, chúng tôi chỉ cần nói: "OK, hãy cung cấp cho chúng tôi các khối dữ liệu được đánh dấu như thế này."

Và người dùng này sẽ làm việc với tập dữ liệu như vậy. Anh ấy sẽ dần dần thay đổi chúng, tạo ra những bức ảnh chụp nhanh của riêng mình.

Và chúng tôi sẽ phân nhánh. Mỗi nhà phát triển trong trường hợp của chúng tôi sẽ có cơ hội có bản sao của riêng mình mà anh ấy chỉnh sửa và dữ liệu được chia sẻ sẽ được chia sẻ giữa mọi người.

Để triển khai một hệ thống như vậy tại nhà, bạn cần giải quyết hai vấn đề:

• Đầu tiên là nguồn dữ liệu, bạn sẽ lấy nó từ đâu. Bạn có thể thiết lập sao chép với sản xuất. Tôi hy vọng bạn đã có thể sử dụng các bản sao lưu mà bạn đã định cấu hình. WAL-E, WAL-G hoặc Barman. Và ngay cả khi bạn đang sử dụng một số loại giải pháp Đám mây như RDS hoặc Cloud SQL, thì bạn vẫn có thể sử dụng các kết xuất hợp lý. Nhưng chúng tôi vẫn khuyên bạn nên sử dụng các bản sao lưu, vì với phương pháp này, bạn cũng sẽ giữ lại cấu trúc vật lý của các tệp, điều này sẽ cho phép bạn tiến gần hơn đến các chỉ số mà bạn sẽ thấy trong quá trình sản xuất để phát hiện những sự cố đang tồn tại.

• Thứ hai là nơi bạn muốn lưu trữ Phòng thí nghiệm cơ sở dữ liệu. Nó có thể là Cloud, nó có thể là On-premise. Điều quan trọng cần nói ở đây là ZFS hỗ trợ nén dữ liệu. Và nó làm điều đó khá tốt.

Hãy tưởng tượng rằng đối với mỗi bản sao như vậy, tùy thuộc vào các hoạt động mà chúng ta thực hiện với cơ sở, một số loại nhà phát triển sẽ phát triển. Đối với điều này, nhà phát triển cũng sẽ cần không gian. Nhưng do chúng tôi lấy cơ sở là 4,5 terabyte, ZFS sẽ nén nó thành 3,5 terabyte. Điều này có thể khác nhau tùy thuộc vào cài đặt. Và chúng ta vẫn còn chỗ cho dev.

Một hệ thống như vậy có thể được sử dụng cho các trường hợp khác nhau.

• Đây là những nhà phát triển, DBA để xác thực truy vấn, để tối ưu hóa.

• Điều này có thể được sử dụng trong kiểm tra QA để kiểm tra một lần di chuyển cụ thể trước khi chúng tôi triển khai nó cho sản xuất. Và chúng tôi cũng có thể nâng cao môi trường đặc biệt cho QA bằng dữ liệu thực, nơi họ có thể thử nghiệm chức năng mới. Và sẽ mất vài giây thay vì hàng giờ chờ đợi, và có thể vài ngày trong một số trường hợp khác không sử dụng bản mỏng.

• Và một trường hợp khác. Nếu công ty không thiết lập hệ thống phân tích, thì chúng tôi có thể tách riêng một bản sao mỏng của cơ sở sản phẩm và đưa nó vào các truy vấn dài hoặc chỉ mục đặc biệt có thể được sử dụng trong phân tích.

Với cách tiếp cận này:

1. Khả năng xảy ra lỗi thấp trên "prod" bởi vì chúng tôi đã thử nghiệm tất cả các thay đổi trên dữ liệu có kích thước đầy đủ.

2. Chúng tôi có văn hóa thử nghiệm, bởi vì giờ đây bạn không phải đợi hàng giờ để có gian hàng của riêng mình.

3. Và không có rào cản, không phải chờ đợi giữa các lần kiểm tra. Bạn thực sự có thể đi và kiểm tra. Và nó sẽ tốt hơn theo cách này khi chúng tôi tăng tốc độ phát triển.

• Sẽ có ít tái cấu trúc hơn. Ít lỗi hơn sẽ kết thúc trong quá trình sản xuất. Chúng tôi sẽ cấu trúc lại chúng ít hơn sau này.

• Chúng ta có thể đảo ngược những thay đổi không thể đảo ngược. Đây không phải là cách tiếp cận tiêu chuẩn.

1. Điều này có lợi vì chúng tôi chia sẻ tài nguyên của băng ghế thử nghiệm.

Đã tốt rồi còn tăng tốc được gì nữa?

Nhờ một hệ thống như vậy, chúng tôi có thể giảm đáng kể ngưỡng tham gia thử nghiệm như vậy.

Bây giờ có một vòng luẩn quẩn, khi một nhà phát triển, để có quyền truy cập vào dữ liệu thực có kích thước đầy đủ, phải trở thành một chuyên gia. Anh ta phải được tin tưởng với quyền truy cập như vậy.

Nhưng làm sao phát triển nếu không có nó. Nhưng nếu bạn chỉ có sẵn một bộ dữ liệu thử nghiệm rất nhỏ thì sao? Sau đó, bạn sẽ không nhận được bất kỳ kinh nghiệm thực tế.

Làm thế nào để thoát ra khỏi vòng tròn này? Là giao diện đầu tiên, thuận tiện cho các nhà phát triển ở mọi cấp độ, chúng tôi đã chọn bot Slack. Nhưng nó có thể là bất kỳ giao diện nào khác.

Nó cho phép bạn làm gì? Bạn có thể lấy một truy vấn cụ thể và gửi nó đến một kênh đặc biệt cho cơ sở dữ liệu. Chúng tôi sẽ tự động triển khai một bản sao mỏng trong vài giây. Hãy chạy yêu cầu này. Chúng tôi thu thập số liệu và đề xuất. Hãy hiển thị một hình dung. Và sau đó bản sao này sẽ vẫn còn để truy vấn này có thể được tối ưu hóa bằng cách nào đó, thêm chỉ mục, v.v.

Và Slack cũng mang đến cho chúng tôi cơ hội hợp tác vượt trội. Vì đây chỉ là một kênh nên bạn có thể bắt đầu thảo luận về yêu cầu này ngay trong chuỗi cho yêu cầu như vậy, ping đồng nghiệp của bạn, các DBA trong công ty.

Nhưng tất nhiên, có những vấn đề. Bởi vì đây là thế giới thực và chúng tôi đang sử dụng một máy chủ lưu trữ nhiều bản sao cùng một lúc, nên chúng tôi phải nén dung lượng bộ nhớ và sức mạnh CPU có sẵn cho các bản sao.

Nhưng để những thử nghiệm này trở nên hợp lý, bạn cần phải giải quyết vấn đề này bằng cách nào đó.

Rõ ràng rằng điểm quan trọng là cùng một dữ liệu. Nhưng chúng tôi đã có nó rồi. Và chúng tôi muốn đạt được cấu hình tương tự. Và chúng ta có thể đưa ra một cấu hình gần như giống hệt như vậy.

Sẽ thật tuyệt nếu có phần cứng giống như trong sản xuất, nhưng nó có thể khác.

Hãy nhớ lại cách Postgres hoạt động với bộ nhớ. Chúng tôi có hai bộ đệm. Một từ hệ thống tệp và một Postgres gốc, tức là Bộ đệm đệm được chia sẻ.

Điều quan trọng cần lưu ý là Shared Buffer Cache được phân bổ khi Postgres bắt đầu, tùy thuộc vào kích thước bạn chỉ định trong cấu hình.

Và bộ đệm thứ hai sử dụng tất cả không gian có sẵn.

Và khi chúng tôi tạo một số bản sao trên một máy, hóa ra chúng tôi sẽ dần lấp đầy bộ nhớ. Và theo một cách tốt, Shared Buffer Cache chiếm 25% tổng dung lượng bộ nhớ khả dụng trên máy.

Và hóa ra là nếu chúng ta không thay đổi tham số này, thì chúng ta sẽ chỉ có thể chạy 4 phiên bản trên một máy, tức là tổng cộng 4 trong số các bản sao mỏng này. Và điều này, tất nhiên, là xấu, bởi vì chúng tôi muốn có nhiều hơn nữa.

Nhưng mặt khác, Bộ đệm đệm được sử dụng để thực hiện các truy vấn cho các chỉ mục, nghĩa là kế hoạch phụ thuộc vào dung lượng bộ đệm của chúng tôi. Và nếu chúng ta chỉ lấy tham số này và giảm nó, thì kế hoạch của chúng ta có thể thay đổi rất nhiều.

Ví dụ: nếu chúng tôi có bộ đệm lớn trên sản phẩm, thì Postgres sẽ ưu tiên sử dụng chỉ mục hơn. Và nếu không, thì sẽ có SeqScan. Và điều gì sẽ xảy ra nếu kế hoạch của chúng tôi không trùng khớp?

Nhưng ở đây chúng ta đi đến kết luận rằng trên thực tế plan trong Postgres không phụ thuộc vào kích thước cụ thể được chỉ định trong Shared Buffer trong plan mà nó phụ thuộc vào effect_cache_size.

Effective_cache_size là lượng bộ đệm ước tính có sẵn cho chúng tôi, tức là tổng của Bộ đệm đệm và bộ đệm hệ thống tệp. Điều này được đặt bởi cấu hình. Và bộ nhớ này không được cấp phát.

Và do tham số này, chúng tôi có thể đánh lừa Postgres, nói rằng chúng tôi thực sự có sẵn rất nhiều dữ liệu, ngay cả khi chúng tôi không có dữ liệu này. Và do đó, các kế hoạch sẽ hoàn toàn trùng khớp với sản xuất.

Nhưng điều này có thể ảnh hưởng đến thời gian. Và chúng tôi tối ưu hóa các truy vấn theo thời gian, nhưng điều quan trọng là thời gian phụ thuộc vào nhiều yếu tố:

• Nó phụ thuộc vào tải hiện tại trên sản phẩm.

• Nó phụ thuộc vào đặc điểm của chính máy.

Và đây là tham số gián tiếp, còn thực tế chúng ta có thể tối ưu chính xác bằng lượng dữ liệu mà câu truy vấn này sẽ đọc để ra kết quả.

Và nếu bạn muốn thời gian gần với những gì chúng ta sẽ thấy trong sản phẩm, thì chúng ta cần sử dụng phần cứng tương tự nhất và thậm chí có thể hơn thế nữa để tất cả các bản sao đều phù hợp. Nhưng đây là một sự thỏa hiệp, tức là bạn sẽ nhận được các kế hoạch giống nhau, bạn sẽ thấy một truy vấn cụ thể sẽ đọc bao nhiêu dữ liệu và bạn sẽ có thể kết luận liệu truy vấn này tốt (hoặc di chuyển) hay không, nó vẫn cần được tối ưu hóa .

Chúng ta hãy xem Joe được tối ưu hóa cụ thể như thế nào.

Hãy lấy một yêu cầu từ một hệ thống thực. Trong trường hợp này, cơ sở dữ liệu là 1 terabyte. Và chúng tôi muốn đếm số lượng bài đăng mới có hơn 10 lượt thích.

Chúng tôi đang viết một tin nhắn cho kênh, một bản sao đã được triển khai cho chúng tôi. Và chúng ta sẽ thấy rằng một yêu cầu như vậy sẽ hoàn thành sau 2,5 phút. Đây là điều đầu tiên chúng tôi nhận thấy.

B Joe sẽ hiển thị cho bạn các đề xuất tự động dựa trên kế hoạch và số liệu.

Chúng ta sẽ thấy rằng truy vấn xử lý quá nhiều dữ liệu để có được số lượng hàng tương đối nhỏ. Và một số loại chỉ mục chuyên biệt là cần thiết, vì chúng tôi nhận thấy rằng có quá nhiều hàng được lọc trong truy vấn.

Chúng ta hãy xem xét kỹ hơn những gì đã xảy ra. Thật vậy, chúng tôi thấy rằng chúng tôi đã đọc gần một gigabyte dữ liệu từ bộ đệm của tệp hoặc thậm chí từ đĩa. Và điều này là không tốt, bởi vì chúng tôi chỉ có 142 dòng.

Và, có vẻ như, chúng tôi có một bản quét chỉ mục ở đây và lẽ ra phải xử lý nhanh chóng, nhưng vì chúng tôi đã lọc ra quá nhiều dòng (chúng tôi phải đếm chúng), nên truy vấn xử lý chậm.

Và điều này đã xảy ra trong kế hoạch do thực tế là các điều kiện trong truy vấn và các điều kiện trong chỉ mục không khớp một phần.

Hãy thử làm cho chỉ mục chính xác hơn và xem cách thực hiện truy vấn thay đổi sau đó.

Việc tạo chỉ mục mất khá nhiều thời gian, nhưng bây giờ chúng tôi kiểm tra truy vấn và thấy rằng thời gian thay vì 2,5 phút chỉ là 156 mili giây, đủ tốt. Và chúng tôi chỉ đọc 6 megabyte dữ liệu.

Và bây giờ chúng tôi chỉ sử dụng quét chỉ mục.

Một câu chuyện quan trọng khác là chúng tôi muốn trình bày kế hoạch theo cách nào đó dễ hiểu hơn. Chúng tôi đã triển khai trực quan hóa bằng Đồ thị ngọn lửa.

Đây là một yêu cầu khác, mãnh liệt hơn. Và chúng tôi xây dựng Đồ thị ngọn lửa theo hai tham số: đây là lượng dữ liệu mà một nút cụ thể được tính trong kế hoạch và thời gian, tức là thời gian thực hiện của nút.

Ở đây chúng ta có thể so sánh các nút cụ thể với nhau. Và sẽ rõ ràng cái nào trong số chúng chiếm nhiều hơn hoặc ít hơn, điều này thường khó thực hiện trong các phương pháp kết xuất khác.

Tất nhiên, mọi người đều biết giải thích.depesz.com. Một tính năng tốt của trực quan hóa này là chúng tôi lưu kế hoạch văn bản và cũng đưa một số tham số cơ bản vào một bảng để chúng tôi có thể sắp xếp.

Và các nhà phát triển chưa đi sâu vào chủ đề này cũng sử dụng giải thích.depesz.com, vì họ dễ dàng tìm ra chỉ số nào quan trọng và chỉ số nào không.

Có một cách tiếp cận mới để trực quan hóa - đây là giải thích.dalibo.com. Họ thực hiện trực quan hóa cây, nhưng rất khó để so sánh các nút với nhau. Ở đây bạn có thể hiểu rõ về cấu trúc, tuy nhiên, nếu có một yêu cầu lớn, thì bạn sẽ cần cuộn qua lại, nhưng cũng có một tùy chọn.

sự hợp tác

Và, như tôi đã nói, Slack cho chúng tôi cơ hội hợp tác. Ví dụ: nếu chúng tôi gặp một truy vấn phức tạp không rõ ràng về cách tối ưu hóa, chúng tôi có thể làm rõ vấn đề này với đồng nghiệp của mình trong một chuỗi trong Slack.

Đối với chúng tôi, có vẻ như điều quan trọng là phải thử nghiệm trên dữ liệu có kích thước đầy đủ. Để thực hiện việc này, chúng tôi đã tạo công cụ Update Database Lab, có sẵn trong nguồn mở. Bạn cũng có thể sử dụng bot Joe. Bạn có thể mang nó ngay bây giờ và thực hiện nó ở nơi của bạn. Tất cả các hướng dẫn có sẵn ở đó.

Cũng cần lưu ý rằng bản thân giải pháp này không mang tính cách mạng vì có Delphix, nhưng nó là một giải pháp doanh nghiệp. Nó hoàn toàn đóng cửa, nó rất đắt. Chúng tôi đặc biệt chuyên về Postgres. Đây đều là những sản phẩm mã nguồn mở. Tham gia với chúng tôi!

Đây là nơi tôi kết thúc. Cảm ơn!

câu hỏi

Xin chào! Cảm ơn bạn đã báo cáo! Rất thú vị, đặc biệt là với tôi, bởi vì tôi đã giải quyết vấn đề tương tự cách đây một thời gian. Và vì vậy tôi có một số câu hỏi. Hy vọng rằng tôi sẽ nhận được ít nhất một phần của nó.

Tôi tự hỏi làm thế nào bạn tính toán địa điểm cho môi trường này? Công nghệ này có nghĩa là trong một số trường hợp nhất định, bản sao của bạn có thể phát triển đến kích thước tối đa. Nói một cách đại khái, nếu bạn có cơ sở dữ liệu mười terabyte và 10 bản sao, thì thật dễ dàng để mô phỏng tình huống trong đó mỗi bản sao nặng 10 dữ liệu duy nhất. Làm thế nào để bạn tính toán nơi này, tức là vùng đồng bằng mà bạn đã nói đến, nơi những bản sao này sẽ sống?

Câu hỏi hay. Điều quan trọng là phải theo dõi các bản sao cụ thể ở đây. Và nếu một bản sao có một số thay đổi quá lớn, nó bắt đầu phát triển, thì trước tiên chúng ta có thể đưa ra cảnh báo cho người dùng về điều này hoặc dừng bản sao này ngay lập tức để chúng ta không gặp phải tình huống thất bại.

Vâng, tôi có một câu hỏi lồng nhau. Đó là, làm thế nào để bạn đảm bảo vòng đời của các mô-đun này? Chúng tôi có vấn đề này và một câu chuyện hoàn toàn riêng biệt. Làm thế nào để điều này xảy ra?

Có một số ttl cho mỗi bản sao. Về cơ bản, chúng tôi có một tệp ttl.

Điều gì, nếu không phải là một bí mật?

1 giờ, tức là không hoạt động - 1 giờ. Nếu nó không được sử dụng, thì chúng tôi đập nó. Nhưng không có gì ngạc nhiên ở đây, vì chúng ta có thể nâng cao bản sao trong vài giây. Và nếu bạn cần nó một lần nữa, sau đó xin vui lòng.

Tôi cũng quan tâm đến việc lựa chọn công nghệ, bởi vì, ví dụ, chúng tôi sử dụng song song một số phương pháp vì lý do này hay lý do khác. Tại sao ZFS? Tại sao bạn không sử dụng LVM? Bạn đã đề cập rằng có vấn đề với LVM. vấn đề là gì? Theo tôi, tùy chọn tối ưu nhất là lưu trữ, xét về hiệu suất.

Vấn đề chính với ZFS là gì? Thực tế là bạn phải chạy trên cùng một máy chủ, tức là tất cả các phiên bản sẽ nằm trong cùng một hệ điều hành. Và trong trường hợp lưu trữ, bạn có thể kết nối các thiết bị khác nhau. Và nút cổ chai chỉ là những khối trên hệ thống lưu trữ. Và câu hỏi về sự lựa chọn công nghệ rất thú vị. Tại sao không LVM?

Cụ thể, chúng ta có thể thảo luận về LVM tại buổi gặp mặt. Về lưu trữ - nó chỉ đắt tiền. Chúng tôi có thể triển khai hệ thống ZFS ở bất cứ đâu. Bạn có thể triển khai nó trên máy của mình. Bạn chỉ cần tải xuống kho lưu trữ và triển khai nó. ZFS được cài đặt ở hầu hết mọi nơi nếu chúng ta đang nói về Linux. Đó là, chúng tôi nhận được một giải pháp rất linh hoạt. Và bản thân ZFS đã mang lại rất nhiều lợi ích. Bạn có thể tải lên bao nhiêu dữ liệu tùy thích, kết nối một số lượng lớn đĩa, có ảnh chụp nhanh. Và, như tôi đã nói, nó rất dễ quản lý. Đó là, nó có vẻ rất dễ chịu khi sử dụng. Anh ấy đã được kiểm tra, anh ấy đã nhiều tuổi. Anh ấy có một cộng đồng rất lớn đang phát triển. ZFS là một giải pháp rất đáng tin cậy.

Nikolai Samokhvalov: Tôi có thể bình luận thêm không? Tên tôi là Nikolay, chúng tôi làm việc cùng với Anatoly. Tôi đồng ý rằng lưu trữ là tuyệt vời. Và một số khách hàng của chúng tôi có Pure Storage, v.v.

Anatoly đã lưu ý chính xác rằng chúng tôi đang tập trung vào tính mô đun. Và trong tương lai, bạn có thể triển khai một giao diện - chụp ảnh nhanh, tạo bản sao, hủy bản sao. Tất cả đều dễ dàng. Và lưu trữ là mát mẻ, nếu nó được.

Nhưng ZFS có sẵn cho tất cả mọi người. DelPhix đã đủ rồi, họ có 300 khách hàng. Trong số này, fortune 100 có 50 khách hàng, tức là họ nhắm đến NASA, v.v. Đã đến lúc mọi người có được công nghệ này. Và đó là lý do tại sao chúng tôi có Core mã nguồn mở. Chúng tôi có một phần giao diện không phải là mã nguồn mở. Đây là nền tảng mà chúng tôi sẽ hiển thị. Nhưng chúng tôi muốn nó có thể truy cập được cho tất cả mọi người. Chúng tôi muốn tạo ra một cuộc cách mạng để tất cả những người thử nghiệm ngừng đoán trên máy tính xách tay. Ta phải viết CHỌN là thấy ngay là chậm. Dừng chờ DBA cho bạn biết về điều đó. Đây là mục tiêu chính. Và tôi nghĩ rằng tất cả chúng ta sẽ đi đến điều này. Và chúng tôi làm điều này cho mọi người có. Do đó, ZFS, vì nó sẽ có sẵn ở mọi nơi. Cảm ơn cộng đồng đã giải quyết vấn đề và có giấy phép mã nguồn mở, v.v.*

Lời chào hỏi! Cảm ơn bạn đã báo cáo! Tên tôi là Maxim. Chúng tôi đã xử lý các vấn đề tương tự. Họ tự quyết định. Làm cách nào để bạn chia sẻ tài nguyên giữa các bản sao này? Mỗi bản sao có thể làm công việc của riêng mình tại bất kỳ thời điểm nào: người này kiểm tra thứ này, người khác làm thứ khác, ai đó xây dựng chỉ mục, ai đó có một công việc nặng nhọc. Và nếu vẫn chia được theo CPU thì chia theo IO thì chia như thế nào ạ? Đây là câu hỏi đầu tiên.

Và câu hỏi thứ hai là về sự khác biệt của khán đài. Giả sử tôi có ZFS ở đây và mọi thứ đều ổn, nhưng ứng dụng khách trên prod không có ZFS, mà là ext4 chẳng hạn. Làm thế nào trong trường hợp này?

Các câu hỏi rất hay. Tôi đã đề cập đến vấn đề này một chút với việc chúng ta chia sẻ tài nguyên. Và giải pháp là đây. Hãy tưởng tượng rằng bạn đang thử nghiệm trên dàn. Bạn cũng có thể gặp phải tình huống như vậy cùng lúc có người cho người này, người cho người khác. Và kết quả là bạn thấy những số liệu khó hiểu. Ngay cả vấn đề tương tự cũng có thể xảy ra với sản phẩm. Khi bạn muốn kiểm tra một số yêu cầu và thấy rằng có một số vấn đề với nó - nó hoạt động chậm, thì thực tế vấn đề không nằm ở yêu cầu mà thực tế là có một loại tải song song nào đó.

Và do đó, điều quan trọng ở đây là tập trung vào kế hoạch sẽ là gì, chúng tôi sẽ thực hiện những bước nào trong kế hoạch và chúng tôi sẽ thu thập bao nhiêu dữ liệu cho việc này. Ví dụ, thực tế là các đĩa của chúng tôi sẽ được tải bằng một thứ gì đó, điều này sẽ ảnh hưởng cụ thể đến thời gian. Nhưng chúng tôi có thể ước tính mức độ tải của yêu cầu này bằng lượng dữ liệu. Nó không quan trọng đến mức đồng thời sẽ có một số loại thực thi.

Tôi có hai câu hỏi. Đây là công cụ rất mát mẻ. Đã có trường hợp nào dữ liệu sản xuất là quan trọng, chẳng hạn như số thẻ tín dụng chưa? Đã có thứ gì đó sẵn sàng chưa hay nó là một nhiệm vụ riêng biệt? Và câu hỏi thứ hai - có cái gì như thế này cho MySQL không?

Về dữ liệu. Chúng tôi sẽ làm obfuscation cho đến khi chúng tôi làm. Nhưng nếu bạn triển khai chính xác Joe, nếu bạn không cấp quyền truy cập cho các nhà phát triển, thì không có quyền truy cập vào dữ liệu. Tại sao? Bởi vì Joe không hiển thị dữ liệu. Nó chỉ hiển thị số liệu, kế hoạch và đó là nó. Điều này được thực hiện có mục đích, bởi vì đây là một trong những yêu cầu của khách hàng của chúng tôi. Họ muốn có thể tối ưu hóa mà không cần cấp cho mọi người quyền truy cập.

Giới thiệu về MySQL. Hệ thống này có thể được sử dụng cho bất kỳ thứ gì lưu trữ trạng thái trên đĩa. Và vì chúng tôi đang thực hiện Postgres, nên chúng tôi hiện đang thực hiện tất cả quá trình tự động hóa cho Postgres trước tiên. Chúng tôi muốn tự động lấy dữ liệu từ bản sao lưu. Chúng tôi đang định cấu hình Postgres chính xác. Chúng tôi biết cách làm cho kế hoạch phù hợp, v.v.

Nhưng vì hệ thống có thể mở rộng nên nó cũng có thể được sử dụng cho MySQL. Và có những ví dụ như vậy. Yandex có một thứ tương tự, nhưng họ không xuất bản nó ở bất cứ đâu. Họ sử dụng nó bên trong Yandex.Metrica. Và chỉ có một câu chuyện về MySQL. Nhưng các công nghệ đều giống nhau, ZFS.

Cảm ơn bạn đã báo cáo! Tôi cũng có một vài câu hỏi. Bạn đã đề cập rằng nhân bản có thể được sử dụng để phân tích, chẳng hạn như để tạo các chỉ mục bổ sung ở đó. Bạn có thể nói thêm một chút về cách thức hoạt động của nó không?

Và tôi sẽ hỏi ngay câu hỏi thứ hai về sự giống nhau của các khán đài, sự giống nhau của các kế hoạch. Kế hoạch cũng phụ thuộc vào số liệu thống kê do Postgres thu thập. Làm thế nào để bạn giải quyết vấn đề này?

Theo phân tích, không có trường hợp cụ thể nào, bởi vì chúng tôi chưa sử dụng nó, nhưng có một cơ hội như vậy. Nếu chúng ta đang nói về các chỉ mục, thì hãy tưởng tượng rằng một truy vấn đang truy vấn một bảng có hàng trăm triệu bản ghi và một cột thường không được lập chỉ mục trong prod. Và chúng tôi muốn tính toán một số dữ liệu ở đó. Nếu yêu cầu này được gửi đến prod, thì có khả năng nó sẽ đơn giản trên prod, vì yêu cầu sẽ được xử lý ở đó trong một phút.

Ok, hãy làm một bản sao mỏng không phải là khủng khiếp để dừng lại trong vài phút. Và để giúp việc đọc phân tích trở nên thoải mái hơn, chúng tôi sẽ thêm các chỉ mục cho những cột mà chúng tôi quan tâm đến dữ liệu.

Chỉ mục sẽ được tạo mỗi lần?

Bạn có thể làm điều đó để chúng tôi chạm vào dữ liệu, tạo ảnh chụp nhanh, sau đó chúng tôi sẽ khôi phục từ ảnh chụp nhanh này và thúc đẩy các yêu cầu mới. Đó là, bạn có thể tạo ra nó để bạn có thể tạo ra các bản sao mới với các chỉ số đã được gắn sẵn.

Đối với câu hỏi về số liệu thống kê, nếu chúng tôi khôi phục từ bản sao lưu, nếu chúng tôi sao chép, thì số liệu thống kê của chúng tôi sẽ giống hệt nhau. Bởi vì chúng tôi có toàn bộ cấu trúc dữ liệu vật lý, nghĩa là chúng tôi cũng sẽ mang dữ liệu về nguyên trạng với tất cả các số liệu thống kê.

Đây là một vấn đề khác. Nếu bạn sử dụng giải pháp đám mây, thì chỉ có các kết xuất logic ở đó, bởi vì Google, Amazon không cho phép bạn lấy một bản sao vật lý. Sẽ có một vấn đề.

Cảm ơn bạn đã báo cáo. Có hai câu hỏi hay ở đây về MySQL và chia sẻ tài nguyên. Tuy nhiên, trên thực tế, tất cả đều bắt nguồn từ thực tế rằng đây không phải là chủ đề của một DBMS cụ thể, mà là của toàn bộ hệ thống tệp. Và theo đó, các vấn đề về chia sẻ tài nguyên cũng nên được giải quyết từ đó, không phải cuối cùng là Postgres, mà là trong hệ thống tệp, chẳng hạn như trong máy chủ.

Câu hỏi của tôi hơi khác một chút. Nó gần với cơ sở dữ liệu nhiều lớp hơn, nơi có nhiều lớp. Ví dụ: chúng tôi thiết lập bản cập nhật hình ảnh mười terabyte, chúng tôi đang sao chép. Và chúng tôi đặc biệt sử dụng giải pháp này cho cơ sở dữ liệu. Quá trình sao chép đang diễn ra, dữ liệu đang được cập nhật. Có 100 nhân viên làm việc song song, họ liên tục tung ra những cảnh quay khác nhau. phải làm gì? Làm thế nào để đảm bảo rằng không có xung đột, rằng họ đã khởi chạy một cái, rồi hệ thống tệp thay đổi và những bức ảnh này biến mất?

Họ sẽ không đi vì đó là cách ZFS hoạt động. Chúng tôi có thể giữ riêng trong một chuỗi các thay đổi hệ thống tệp do sao chép. Và giữ các bản sao mà các nhà phát triển sử dụng trên các phiên bản dữ liệu cũ hơn. Và nó hoạt động với chúng tôi, mọi thứ đều phù hợp với điều này.

Nó chỉ ra rằng bản cập nhật sẽ diễn ra dưới dạng một lớp bổ sung và tất cả các hình ảnh mới sẽ được thực hiện dựa trên lớp này, phải không?

Từ các lớp trước đó là từ các bản sao trước đó.

Các lớp trước đó sẽ rơi ra, nhưng chúng sẽ tham chiếu đến lớp cũ và liệu chúng có chụp ảnh mới từ lớp cuối cùng nhận được trong bản cập nhật không?

Nói chung, có.

Sau đó, kết quả là chúng ta sẽ có tới một con số các lớp. Và theo thời gian chúng sẽ cần được nén lại?

Có tất cả mọi thứ là chính xác. Có một số cửa sổ. Chúng tôi giữ ảnh chụp nhanh hàng tuần. Nó phụ thuộc vào tài nguyên bạn có. Nếu bạn có khả năng lưu trữ nhiều dữ liệu, bạn có thể lưu trữ ảnh chụp nhanh trong một thời gian dài. Chúng sẽ không tự biến mất. Sẽ không có dữ liệu tham nhũng. Nếu ảnh chụp nhanh đã lỗi thời, như đối với chúng tôi, tức là nó phụ thuộc vào chính sách trong công ty, thì chúng tôi chỉ cần xóa chúng và giải phóng dung lượng.

Xin chào, cảm ơn vì đã báo cáo! Câu hỏi về Joe. Bạn nói rằng khách hàng không muốn cấp cho mọi người quyền truy cập vào dữ liệu. Nói đúng ra, nếu một người có kết quả của Phân tích giải thích, thì anh ta có thể xem dữ liệu.

Nó là như vậy. Ví dụ, chúng ta có thể viết: "SELECT FROM WHERE email = to that". Đó là, chúng ta sẽ không nhìn thấy dữ liệu, nhưng chúng ta có thể thấy một số dấu hiệu gián tiếp. Điều này phải được hiểu. Nhưng mặt khác, tất cả đều ở đó. Chúng tôi có kiểm tra nhật ký, chúng tôi có quyền kiểm soát các đồng nghiệp khác, những người cũng xem những gì các nhà phát triển đang làm. Và nếu ai đó cố gắng làm điều này, thì dịch vụ bảo mật sẽ đến gặp họ và giải quyết vấn đề này.

Chào buổi chiều Cảm ơn bạn đã báo cáo! Tôi có một câu hỏi ngắn. Nếu công ty không sử dụng Slack thì hiện tại có bất kỳ ràng buộc nào với Slack hay các nhà phát triển có thể triển khai các phiên bản để kết nối ứng dụng thử nghiệm với cơ sở dữ liệu không?

Bây giờ có một liên kết đến Slack, tức là không có trình nhắn tin nào khác, nhưng tôi thực sự muốn hỗ trợ cho các trình nhắn tin khác nữa. Bạn có thể làm gì? Bạn có thể triển khai DB Lab mà không cần Joe, với sự trợ giúp của API REST hoặc với sự trợ giúp của nền tảng của chúng tôi, đồng thời tạo các bản sao và kết nối với PSQL. Nhưng điều này có thể được thực hiện nếu bạn sẵn sàng cấp cho nhà phát triển của mình quyền truy cập vào dữ liệu, vì sẽ không còn bất kỳ màn hình nào nữa.

Tôi không cần lớp này, nhưng tôi cần một cơ hội như vậy.

Sau đó, có, nó có thể được thực hiện.

Nguồn: www.habr.com