Câu hỏi Tại sao tham gia xấu khi xem xét khả năng mở rộng?


Tại sao tham gia xấu hoặc 'chậm'. Tôi biết tôi đã nghe điều này nhiều hơn rồi một lần. Tôi tìm thấy trích dẫn này

Vấn đề là sự tham gia tương đối   chậm, đặc biệt là trên dữ liệu rất lớn   và nếu chúng chậm   trang web chậm. Phải mất một thời gian dài   để có được tất cả các bit riêng biệt đó   thông tin tắt đĩa và đặt tất cả   lại với nhau.

nguồn

Tôi luôn nghĩ rằng họ đã nhanh chóng đặc biệt là khi tìm kiếm một PK. Tại sao chúng 'chậm'?


76
2018-04-12 17:02


gốc




Các câu trả lời:


Tham gia hai nguồn dữ liệu riêng biệt tương đối chậm, ít nhất so với việc không tham gia chúng. Nhưng hãy nhớ rằng thay thế là không còn có hai phần dữ liệu riêng biệt nữa; bạn phải đặt hai điểm dữ liệu khác nhau trong cùng một bản ghi. Bạn không thể kết hợp hai phần dữ liệu khác nhau mà không có kết quả ở đâu đó, vì vậy hãy đảm bảo bạn hiểu được sự cân bằng.

Tin tốt là các cơ sở dữ liệu quan hệ hiện đại tốt tại gia nhập. Bạn không nên thực sự nghĩ rằng tham gia như là chậm với một cơ sở dữ liệu tốt. Cơ sở dữ liệu cung cấp một số cách để tham gia thô và làm cho chúng nhiều nhanh hơn:

  • Tham gia vào một khóa thay thế (autonumer / identity cột) chứ không phải là một khóa tự nhiên. Điều này có nghĩa là các so sánh nhỏ hơn (và do đó nhanh hơn) trong quá trình kết nối
  • Chỉ mục
  • Chế độ xem được lập chỉ mục / được lập chỉ mục (nghĩ về điều này như là một kết nối được tính toán trước hoặc được quản lý khử bình thường)
  • Cột được tính toán. Bạn có thể sử dụng tính năng này để băm hoặc tính toán trước các cột chính của một phép nối, như vậy việc so sánh phức tạp cho một phép nối bây giờ nhỏ hơn nhiều và có khả năng lập chỉ mục trước.
  • Phân vùng bảng (giúp với các tập dữ liệu lớn bằng cách trải rộng tải ra nhiều đĩa, hoặc giới hạn những gì có thể là một bảng quét xuống để quét phân vùng)
  • OLAP (tính toán trước các kết quả của các loại truy vấn / tham gia nhất định. Nó không hoàn toàn đúng, nhưng bạn có thể nghĩ về điều này là chung không chuẩn hóa)

Tôi sẽ đi xa như vậy để nói rằng lý do chính cơ sở dữ liệu quan hệ tồn tại ở tất cả là cho phép bạn tham gia hiệu quả*. Nó chắc chắn không chỉ lưu trữ dữ liệu có cấu trúc (bạn có thể làm điều đó với các cấu trúc tệp phẳng như csv hoặc xml). Một vài tùy chọn mà tôi liệt kê thậm chí sẽ cho phép bạn hoàn toàn xây dựng kết nối của bạn trước, do đó kết quả đã được thực hiện trước khi bạn đưa ra truy vấn - cũng giống như nếu bạn đã chuẩn hóa dữ liệu (thừa nhận là chi phí cho hoạt động ghi chậm hơn).

Nếu bạn tham gia chậm, có thể bạn không sử dụng đúng cơ sở dữ liệu của mình. 

Việc bình thường hóa chỉ nên được thực hiện sau khi các kỹ thuật khác đã thất bại. Và cách duy nhất bạn thực sự có thể đánh giá "thất bại" là đặt mục tiêu hiệu suất có ý nghĩa và đo lường chống lại những mục tiêu đó. Nếu bạn chưa đo, thì còn quá sớm để thậm chí suy nghĩ về việc bình thường hóa.

* Đó là, tồn tại như các thực thể khác biệt với các bộ sưu tập bảng. Một lý do bổ sung cho một rdbms thực là truy cập đồng thời an toàn.


76
2018-04-12 17:23



Các chỉ mục có thể nằm ở đầu danh sách. Rất nhiều (ho) các nhà phát triển dường như quên chúng khi thử nghiệm trên một tập dữ liệu nhỏ và sau đó đưa cơ sở dữ liệu đến đầu gối của nó trong sản xuất. Tôi đã thấy các truy vấn chạy nhanh hơn 100.000 lần đơn giản bằng cách thêm các chỉ mục. Và đó là các chỉ mục tùy ý mà thậm chí không thực hiện bất kỳ phân tích dữ liệu chuyên sâu nào để xác định kết hợp tốt nhất cho phù hợp với tiền tố tận cùng bên trái. - Duncan
Tôi nghĩ rằng tôi có thứ tự đúng - nó chỉ là hầu hết các nhà phát triển đã làm mục đầu tiên, và vì vậy chỉ số là mục đầu tiên mà họ sẽ cần phải thực hiện thay đổi. - Joel Coehoorn
Trong mục thứ ba của bạn, bạn đề cập đến "Chế độ xem được lập chỉ mục / được lập chỉ mục". Bạn đang nói về các khung nhìn SQL thông thường, hay cái gì khác? - slolife
@slolife chế độ xem sql thông thường giống như chạy truy vấn bổ sung trong nền khi đang di chuyển khi bạn sử dụng truy vấn tham chiếu chế độ xem. Nhưng bạn cũng có thể nói với máy chủ sql để "thực hiện" một số quan điểm. Khi bạn làm điều này, máy chủ sql sẽ giữ một bản sao bổ sung của dữ liệu của khung nhìn, giống như một bảng thông thường, như vậy khi bạn tham chiếu khung nhìn trong một truy vấn, nó không còn phải chạy truy vấn này dưới nền vì dữ liệu đã có . Bạn cũng có thể đặt các chỉ mục khác nhau trên chế độ xem so với bảng nguồn, để giúp bạn điều chỉnh hiệu suất hơn nữa. - Joel Coehoorn
Cảm ơn Joel. Tôi sẽ phải nhìn vào đó. - slolife


Tham gia có thể là chậm hơn hơn là tránh chúng qua khử chuẩn hóa nhưng nếu được sử dụng đúng cách (tham gia vào các cột có chỉ mục thích hợp, vv) họ vốn không chậm.

De-normalization là một trong nhiều kỹ thuật tối ưu hóa bạn có thể xem xét nếu lược đồ cơ sở dữ liệu được thiết kế tốt của bạn thể hiện các vấn đề về hiệu suất.


28
2018-04-12 17:11



... ngoại trừ trong MySQL, có vẻ như có vấn đề về hiệu suất với số lượng lớn các kết nối bất kể các chỉ mục của bạn trông như thế nào. Hoặc ít nhất nó có trong quá khứ. - Powerlord
Điểm được thực hiện, nếu có các vấn đề đã biết với DBMS cụ thể (và thậm chí cả phiên bản) thì lời khuyên này có thể có ý nghĩa, nhưng theo lời khuyên chung thì nó khá là sai lầm nếu bạn đang sử dụng cơ sở dữ liệu quan hệ. Điều đó nói rằng các cơ chế lưu trữ phi quan hệ đang trở nên phổ biến hơn của SimpleDB và CouchDB của Amazon (couchdb.apache.org) là những ví dụ. Nếu bạn được phục vụ tốt hơn bằng cách rời khỏi mô hình quan hệ phía sau, bạn có lẽ nên để các sản phẩm được tối ưu hóa cho phía sau và tìm kiếm các công cụ khác. - Tendayi Mawushe


bài viết nói rằng chúng chậm khi so sánh với sự vắng mặt của các phép nối. điều này có thể đạt được với sự không chuẩn hóa. do đó, có một sự giao dịch giữa tốc độ và bình thường hóa. đừng quên về tối ưu hóa sớm cũng :)


12
2018-04-12 17:08



thậm chí đây không phải là một quy tắc cứng, nếu bạn tham gia vào một bảng, mysql có thể sử dụng một chỉ mục để thực hiện phép nối đó - tham số chỉ mục đó có thể cắt tỉa nhiều hàng và một chỉ mục khác cho bất kỳ mệnh đề where nào trên các bảng. Nếu bạn không tham gia, mysql thường sẽ chỉ sử dụng một chỉ mục (có thể không phải là chỉ mục hiệu quả nhất), bất kể mệnh đề where của bạn được hình thành ở đâu. - leeeroy


Trước hết, một raison d'etre của cơ sở dữ liệu quan hệ (lý do là) ​​là để có thể mô hình hóa mối quan hệ giữa các thực thể. Tham gia đơn giản là các cơ chế mà qua đó chúng ta đi qua các mối quan hệ đó. Họ chắc chắn không có chi phí danh nghĩa, nhưng không có sự tham gia, thực sự không có lý do gì để có một cơ sở dữ liệu quan hệ.

Trong thế giới học thuật, chúng ta học về những thứ như các dạng bình thường khác nhau (1, 2, 3, Boyce-Codd, vv), và chúng ta tìm hiểu về các loại khóa khác nhau (chính, nước ngoài, thay thế, duy nhất, v.v.) và cách những thứ này phù hợp với nhau để thiết kế một cơ sở dữ liệu. Và chúng tôi tìm hiểu các nguyên tắc của SQL cũng như thao tác cả cấu trúc và dữ liệu (DDL & DML).

Trong thế giới doanh nghiệp, nhiều cấu trúc học thuật hóa ra ít khả thi hơn chúng ta đã được tin tưởng. Một ví dụ hoàn hảo là khái niệm của một khóa chính. Về mặt học thuật, đó là thuộc tính (hoặc tập hợp các thuộc tính) xác định duy nhất một hàng trong bảng. Vì vậy, trong nhiều lĩnh vực vấn đề, khóa học chính thích hợp là một tổng hợp của 3 hoặc 4 thuộc tính. Tuy nhiên, hầu như tất cả mọi người trong thế giới doanh nghiệp hiện đại sử dụng số nguyên tuần tự được tạo tự động làm khóa chính của bảng. Tại sao? Hai lý do. Đầu tiên là vì nó làm cho mô hình trở nên sạch hơn khi bạn di chuyển các FK khắp nơi. Thứ hai, và hầu hết các germane cho câu hỏi này, là lấy dữ liệu thông qua tham gia là nhanh hơn và hiệu quả hơn trên một số nguyên duy nhất hơn là trên 4 cột varchar (như đã được đề cập bởi một vài folks).

Bây giờ chúng ta hãy đào sâu hơn một chút vào hai kiểu con cụ thể của cơ sở dữ liệu thế giới thực. Loại đầu tiên là một cơ sở dữ liệu giao dịch. Đây là cơ sở cho nhiều ứng dụng quản lý nội dung hoặc thương mại điện tử thúc đẩy các trang web hiện đại. Với DB giao dịch, bạn đang tối ưu hóa rất nhiều cho "thông lượng giao dịch". Hầu hết các ứng dụng thương mại hoặc nội dung phải cân bằng hiệu suất truy vấn (từ một số bảng nhất định) với hiệu suất chèn (trong các bảng khác), mặc dù mỗi ứng dụng sẽ có các vấn đề kinh doanh độc đáo riêng để giải quyết.

Loại thứ hai của cơ sở dữ liệu thực tế là một cơ sở dữ liệu báo cáo. Chúng được sử dụng hầu như chỉ để tổng hợp dữ liệu nghiệp vụ và tạo ra các báo cáo kinh doanh có ý nghĩa. Chúng thường có hình dạng khác với cơ sở dữ liệu giao dịch nơi dữ liệu được tạo và chúng được tối ưu hóa cao cho tốc độ tải dữ liệu hàng loạt (ETL) và hiệu suất truy vấn với các tập dữ liệu lớn hoặc phức tạp.

Trong mỗi trường hợp, nhà phát triển hoặc DBA cần cân nhắc cẩn thận cả chức năng và đường cong hiệu suất và có rất nhiều thủ thuật nâng cao hiệu suất trên cả hai mặt của phương trình. Trong Oracle, bạn có thể thực hiện những gì được gọi là "kế hoạch giải thích" để bạn có thể thấy cụ thể cách truy vấn được phân tích cú pháp và thực thi. Bạn đang tìm cách tối đa hóa việc sử dụng các chỉ mục thích hợp của DB. Một thực sự khó chịu no-no là đặt một hàm trong mệnh đề where của truy vấn. Bất cứ khi nào bạn làm điều đó, bạn đảm bảo rằng Oracle sẽ không sử dụng bất kỳ chỉ mục nào trên cột cụ thể đó và bạn có thể sẽ thấy một bảng quét toàn bộ hoặc một phần trong kế hoạch giải thích. Đó chỉ là một ví dụ cụ thể về cách một truy vấn có thể được viết mà kết thúc lên được làm chậm, và nó không có bất cứ điều gì để làm với tham gia.

Và trong khi chúng ta đang nói về quét bảng, chúng rõ ràng tác động đến tốc độ truy vấn tương ứng với kích thước của bảng. Quét toàn bộ 100 hàng thậm chí không đáng chú ý. Chạy cùng một truy vấn đó trên một bảng với 100 triệu hàng và bạn sẽ cần phải quay lại vào tuần tới để trả về.

Hãy nói về bình thường hóa trong một phút. Đây là một chủ đề học thuật tích cực khác có thể bị căng thẳng quá mức. Hầu hết thời gian chúng ta nói về bình thường hóa, chúng tôi thực sự có nghĩa là loại bỏ dữ liệu trùng lặp bằng cách đặt nó vào bảng riêng của nó và di chuyển một FK. Folks thường bỏ qua toàn bộ sự phụ thuộc được mô tả bởi 2NF và 3NF. Và trong một trường hợp cực đoan, chắc chắn có thể có một cơ sở dữ liệu BCNF hoàn hảo rất lớn và một con thú hoàn chỉnh để viết mã chống lại vì nó đã được chuẩn hóa.

Vậy chúng ta cân bằng ở đâu? Không có câu trả lời hay nhất. Tất cả các câu trả lời tốt hơn có xu hướng là một số thỏa hiệp giữa dễ bảo trì cấu trúc, dễ bảo trì dữ liệu và dễ tạo mã / bảo trì. Nói chung, việc sao chép ít dữ liệu càng tốt.

Vậy tại sao đôi khi tham gia chậm? Đôi khi đó là thiết kế quan hệ xấu. Đôi khi nó không lập chỉ mục hiệu quả. Đôi khi đó là vấn đề về khối lượng dữ liệu. Đôi khi nó là một truy vấn khủng khiếp bằng văn bản.

Xin lỗi vì câu trả lời dài dòng như vậy, nhưng tôi cảm thấy bắt buộc phải cung cấp ngữ cảnh thịt hơn ý kiến ​​của tôi thay vì chỉ rít lên một phản ứng 4 viên đạn.


10
2018-04-13 01:00





Những người có terrabyte có kích thước cơ sở dữ liệu vẫn sử dụng tham gia, nếu họ có thể làm cho họ làm việc hiệu quả khôn ngoan thì bạn cũng vậy.

Có nhiều lý do để không làm mất hiệu lực. Thứ nhất, tốc độ truy vấn chọn lọc không phải là mối quan tâm duy nhất hoặc thậm chí chính với cơ sở dữ liệu. Tính toàn vẹn của dữ liệu là mối quan tâm đầu tiên. Nếu bạn không chuẩn hóa thì bạn phải đưa vào các kỹ thuật để giữ cho dữ liệu không được chuẩn hóa khi dữ liệu gốc thay đổi. Vì vậy, giả sử bạn thực hiện việc lưu trữ tên máy khách trong tất cả các bảng thay vì tham gia vào bảng khách hàng trên client_Id. Bây giờ khi tên của khách hàng thay đổi (100% cơ hội một số tên của khách hàng sẽ thay đổi theo thời gian), bây giờ bạn cần cập nhật tất cả các bản ghi con để phản ánh thay đổi đó. Nếu bạn làm điều này với một bản cập nhật xếp tầng và bạn có một triệu bản ghi con, bạn cho rằng sẽ nhanh như thế nào và có bao nhiêu người dùng sẽ gặp vấn đề về khóa và sự chậm trễ trong công việc của họ trong khi nó xảy ra? Hơn nữa hầu hết những người không chuẩn hóa vì "tham gia chậm" không biết đủ về cơ sở dữ liệu để đảm bảo tính toàn vẹn dữ liệu của họ được bảo vệ và thường kết thúc với cơ sở dữ liệu có dữ liệu không sử dụng được vì tính toàn vẹn quá tệ.

Việc không chuẩn hóa là một quá trình phức tạp đòi hỏi sự hiểu biết thấu đáo về hiệu suất cơ sở dữ liệu và tính toàn vẹn nếu nó được thực hiện đúng. Đừng cố gắng làm bất bình thường trừ khi bạn có chuyên môn về nhân viên.

Tham gia đủ nhanh nếu bạn làm vài việc. Đầu tiên sử dụng một khóa suggorgate, một tham gia int là gần như alawys tham gia nhanh nhất. Thứ hai luôn lập chỉ mục khóa ngoại. Sử dụng các bảng có nguồn gốc hoặc tham gia các điều kiện để tạo một tập dữ liệu nhỏ hơn để lọc. Nếu bạn có một cơ sở dữ liệu rất phức tạp, thì hãy thuê một người có cơ sở dữ liệu chuyên nghiệp với kinh nghiệm trong việc chia cắt và quản lý các cơ sở dữ liệu khổng lồ. Có rất nhiều kỹ thuật để cải thiện hiệu suất mà không phải loại bỏ các kết nối.

Nếu bạn chỉ cần khả năng truy vấn, thì có bạn có thể thiết kế một datawarehouse có thể được denormalized và được phổ biến thông qua một công cụ ETL (tối ưu hóa cho tốc độ) không nhập dữ liệu người dùng.


9
2018-04-12 17:44





Tham gia chậm nếu

  • dữ liệu được lập chỉ mục không đúng cách
  • kết quả kém lọc
  • tham gia truy vấn kém bằng văn bản
  • dữ liệu đặt rất lớn và phức tạp

Vì vậy, đúng hơn, dữ liệu của bạn càng lớn thì bộ xử lý càng cần cho truy vấn nhưng việc kiểm tra và làm việc trên ba tùy chọn đầu tiên ở trên thường mang lại kết quả tuyệt vời.

Nguồn của bạn cho phép không chuẩn hóa như một tùy chọn. Điều này là tốt chỉ miễn là bạn đã cạn kiệt lựa chọn thay thế tốt hơn.


8
2018-04-12 17:13





Các kết nối có thể chậm nếu các phần lớn các bản ghi từ mỗi bên cần phải được quét.

Như thế này:

SELECT  SUM(transaction)
FROM    customers
JOIN    accounts
ON      account_customer = customer_id

Ngay cả khi chỉ mục được xác định account_customer, tất cả các bản ghi từ thứ hai vẫn cần phải được quét.

Đối với danh sách truy vấn này, các trình tối ưu hóa phong nha thậm chí sẽ không xem xét đến đường dẫn truy cập chỉ mục, thực hiện HASH JOIN hoặc một MERGE JOIN thay thế.

Lưu ý rằng đối với một truy vấn như thế này:

SELECT  SUM(transaction)
FROM    customers
JOIN    accounts
ON      account_customer = customer_id
WHERE   customer_last_name = 'Stellphlug'

sự tham gia sẽ có lẽ sẽ nhanh nhất: đầu tiên, một chỉ mục trên customer_last_name sẽ được sử dụng để lọc tất cả các Stellphlug (tất nhiên, không phải là rất nhiều), sau đó quét chỉ mục account_customer sẽ được phát hành cho mỗi Stellphlug để tìm các giao dịch của anh ta.

Mặc dù thực tế rằng đây có thể là hàng tỷ hồ sơ trong accounts và customers, chỉ một số ít thực sự cần phải được quét.


7
2018-04-12 17:07



nhưng rất khó để tránh nó. thiết kế ứng dụng của bạn để loại truy vấn này không được thực hiện quá thường xuyên. - Andrey
Nếu chỉ mục được xác định trên accounts(account_customer) hầu hết các RDBMS sẽ sử dụng chỉ mục đó để tìm ra chính xác những hàng nào của customers cơ sở dữ liệu cần được quét. - jemfinch
có, nhưng nó không phải là hoạt động giá rẻ anyway. bạn có thể lưu trữ tổng trong một số trường và cập nhật trong mỗi giao dịch. - Andrey
@ jemfinch: không, họ sẽ không. Điều này sẽ yêu cầu quét toàn bộ chỉ mục để lọc ra khách hàng, sau đó quét chỉ mục của khách hàng trong một vòng lặp lồng nhau. A HASH JOIN sẽ nhanh hơn nhiều vì vậy nó sẽ được sử dụng ngoại trừ trong tất cả các cơ sở dữ liệu chính ngoại trừ MySQL, mà sẽ chỉ làm cho customers dẫn đầu trong một vòng lặp lồng nhau (vì nó có kích thước nhỏ hơn) - Quassnoi


Tham gia không yêu cầu xử lý thêm vì chúng phải tìm kiếm nhiều tệp hơn và nhiều chỉ mục hơn để "nối" dữ liệu với nhau. Tuy nhiên, "tập dữ liệu rất lớn" là tất cả tương đối. Định nghĩa lớn là gì? Tôi là trường hợp JOIN, tôi nghĩ đó là một tham chiếu đến một tập kết quả lớn, không phải là tập dữ liệu tổng thể.

Hầu hết các cơ sở dữ liệu có thể xử lý nhanh một truy vấn chọn 5 bản ghi từ một bảng chính và nối 5 bản ghi từ một bảng có liên quan cho mỗi bản ghi (giả sử các chỉ mục chính xác được đặt ra). Những bảng này có thể có hàng trăm triệu bản ghi, hoặc thậm chí hàng tỷ.

Khi tập kết quả của bạn bắt đầu phát triển, mọi thứ sẽ chậm lại. Sử dụng cùng một ví dụ, nếu bảng chính kết quả trong bản ghi 100K, thì sẽ có 500K "được nối" bản ghi cần tìm. Chỉ cần kéo nhiều dữ liệu ra khỏi cơ sở dữ liệu với thêm sự chậm trễ.

Đừng tránh JOIN, chỉ cần biết bạn có thể cần tối ưu hóa / không chuẩn hóa khi các tập dữ liệu nhận được "rất lớn".


3
2018-04-12 17:45





Tham gia được coi là một lực lượng đối lập với khả năng mở rộng bởi vì họ thường là nút cổ chai và họ không thể dễ dàng phân phối hoặc song song.


2
2018-04-12 17:09



Tôi không chắc điều này là đúng. Tôi biết Teradata chắc chắn có thể phân phối các kết nối giữa Amps. Rõ ràng là một số loại tham gia có thể phức tạp hơn / có thể thu hút hơn những loại khác. - Cade Roux
chỉ mục có thể được phân vùng trong RDBMS khác nhau, từ mysql đến oracle. AFAIK quy mô (được phân phối và có thể song song). - Unreason


Các bảng được thiết kế đúng cách chứa các chỉ dẫn thích hợp và các truy vấn được viết đúng cách không phải lúc nào cũng chậm. Bạn đã bao giờ nghe nói rằng:

Tại sao tham gia xấu hoặc 'chậm'

không biết họ đang nói về cái gì !!! Hầu hết các cuộc tham gia sẽ rất nhanh. Nếu bạn phải tham gia nhiều nhiều hàng cùng một lúc, bạn có thể lấy một lần truy cập so với bảng không chuẩn hóa, nhưng lại quay lại bảng được thiết kế đúng, biết khi nào không chuẩn hóa và khi nào thì không. trong một hệ thống báo cáo nặng, tách ra các dữ liệu trong các bảng không chuẩn hóa cho các báo cáo, hoặc thậm chí tạo ra một kho dữ liệu. Trong một hệ thống nặng giao dịch bình thường hóa các bảng.


2
2018-04-12 17:09





Joins are fast. Tham gia nên được coi là thực hành tiêu chuẩn với lược đồ cơ sở dữ liệu được chuẩn hóa đúng cách. Tham gia cho phép bạn tham gia các nhóm dữ liệu khác nhau theo cách có ý nghĩa. Đừng sợ tham gia.

Thông báo trước là bạn phải hiểu việc chuẩn hóa, tham gia và sử dụng đúng các chỉ mục.

Hãy coi chừng tối ưu hóa sớm, như số một thất bại của tất cả các dự án phát triển là đáp ứng thời hạn. Một khi bạn đã hoàn thành dự án, và bạn hiểu được thương mại, bạn có thể phá vỡ các quy tắc nếu bạn có thể biện minh cho nó.

Đúng là tham gia hiệu suất sẽ giảm xuống không tuyến tính khi kích thước của tập dữ liệu tăng lên. Vì vậy, nó không quy mô độc đáo như truy vấn bảng duy nhất, nhưng nó vẫn còn quy mô.

Nó cũng đúng là một con chim bay nhanh hơn mà không có đôi cánh, nhưng chỉ thẳng xuống.


2
2018-04-12 18:02