Để cải thiện hiệu suất SQL, tại sao không chỉ đặt nhiều RAM thay vì có đĩa cứng nhanh hơn?

Mọi người cứ nói với tôi rằng để cải thiện hiệu năng của máy chủ SQL, hãy mua đĩa cứng nhanh nhất có thể với RAID 5, v.v.

Vì vậy, tôi đã suy nghĩ, thay vì chi tất cả tiền cho RAID 5 và đĩa cứng siêu nhanh nhân đôi (không phải là rẻ bằng cách này), tại sao không chỉ có hàng tấn RAM? Chúng tôi biết rằng một máy chủ SQL tải cơ sở dữ liệu vào bộ nhớ. Bộ nhớ nhanh hơn bất kỳ ổ cứng nào.

Tại sao không nhét vào như 100 GB RAM trên máy chủ? Sau đó, chỉ cần sử dụng đĩa cứng SCSI thông thường với RAID 1. Sẽ không rẻ hơn và nhanh hơn sao?

Phân tích của bạn là tốt - đến một điểm - trong đó nó hoàn toàn sẽ làm cho mọi thứ nhanh hơn. Bạn vẫn phải tính đến một vài vấn đề khác:

1. Không phải ai cũng có đủ khả năng ghi nhớ; Khi bạn có nhiều terabyte dữ liệu, bạn phải đặt nó vào đĩa một thời gian. Nếu bạn không có nhiều dữ liệu, mọi thứ đều đủ nhanh.

2. Hiệu suất ghi cho cơ sở dữ liệu của bạn vẫn sẽ bị hạn chế bởi các đĩa, do đó bạn có thể giữ lời hứa rằng dữ liệu đã được lưu trữ thực sự.

Nếu bạn có một tập dữ liệu nhỏ hoặc không cần phải lưu nó trên đĩa, ý tưởng của bạn không có gì sai. Các công cụ như VoltDB đang làm việc để giảm chi phí mà các giả định cũ hơn trong các triển khai RDBMS được thực hiện nhằm hạn chế hiệu năng trong bộ nhớ thuần túy.

. hầu như luôn luôn là hạn chế sản xuất - bởi vì bạn có thể ném RAM vào bộ nhớ đệm để giải quyết hầu hết các vấn đề về hiệu suất phía đọc.)

Phiên bản ngắn: xem xét kích thước bộ làm việc. Phiên bản dài: Dữ liệu của bạn lớn như thế nào? Nếu nó có thể phù hợp với bộ nhớ của một máy chủ hiện đại, vâng, bạn hoàn toàn đúng. Thật không may, Xeon lớn nhất có thể xử lý 2TB RAM ngay bây giờ và đó không phải là một bộ dữ liệu lớn nữa. Nếu bạn không thể mua máy đủ lớn để chứa toàn bộ bộ làm việc của mình trong RAM, bạn buộc phải giải quyết vấn đề với bộ não của mình chứ không phải ví của bạn.

Nếu bạn muốn tốc độ:

• Tăng RAM để ít nhất các chỉ mục được sử dụng thường xuyên hoàn toàn có thể phù hợp với RAM (ví dụ: trên hệ thống tôi làm việc, RAM 32 GB có rất nhiều cho cơ sở dữ liệu 350 GB, vì các chỉ mục là thứ bạn cần trong RAM, không phải dữ liệu thô)
• Sử dụng RAID10 với bất kỳ đĩa nào (đĩa nhanh hơn sẽ tốt hơn)
• Tránh RAID5
• Tách mdf, ldf và temp DB thành các bộ trục chính rời rạc (ví dụ: tempdb trên bộ RAID1 của chính nó, ldf trên bộ trục chính RAID1 hoặc RAID10 của riêng nó, mdf trên bộ RAID 10 có ít nhất 4 đĩa)

Thực hiện theo các bước đó và SQL Server sẽ bay.

Sau đó, nếu bạn muốn, hãy thêm RAM ... nhưng hãy thực hiện ở trên trước và bạn cũng có thể thấy mình đã hoàn thành.

RAM là đĩa mới, đĩa là băng mới.

Trong http://www.tbray.org/ongceed/When/200x/2006/05/24/On-Grids . Lưu ý rằng đó là sáu năm trước. Có, chúng tôi có các hệ thống cơ sở dữ liệu cố gắng (và cố gắng hết sức) để giữ toàn bộ dữ liệu trong RAM và thay vì sử dụng nhiều máy hơn là sử dụng đĩa vì dù sao đĩa cũng có cường độ chậm hơn. Bạn cần ghi dữ liệu vào đĩa nhưng như phương châm trên, nó gần giống với tác vụ sao lưu nền hơn là thao tác trực tuyến. Độ bền đạt được thông qua việc nối thêm các bản ghi với các cơ sở dữ liệu này (tôi đang nghĩ MongoDB và Redis nhưng có rất nhiều thứ khác).

Câu hỏi này tương tự như một câu hỏi cơ bản đã dẫn đến rất nhiều nghiên cứu và phát triển về kiến ​​trúc cơ sở dữ liệu trong 5-10 năm qua. Bây giờ có thể lưu trữ toàn bộ cơ sở dữ liệu trong RAM cho nhiều trường hợp sử dụng, cơ sở dữ liệu cần được thiết kế xung quanh hoạt động trong RAM, thay vì chỉ áp dụng các kiến ​​trúc kế thừa cũ hơn vào lưu trữ dựa trên RAM.

Cũng giống như nhiều ngôn ngữ nhỏ hơn và có mục đích đặc biệt hơn đã được áp dụng rộng rãi trong những năm gần đây, chúng ta đang bước vào kỷ nguyên cơ sở dữ liệu cho mục đích đặc biệt hơn.

Đối với một số bài đọc thêm về chủ đề này, tôi đề nghị bài báo học thuật Kết thúc một kỷ nguyên kiến ​​trúc (Đã đến lúc viết lại hoàn chỉnh) . Nó không phải là một khó đọc.

Không rõ câu hỏi này có cụ thể về SQL Server không. Các poster ban đầu nên làm rõ điều này.

Daniel Pittman đã viết:

Nếu bạn có một tập dữ liệu nhỏ hoặc không cần phải lưu nó trên đĩa, không có gì sai> với ý tưởng của bạn. Các công cụ như VoltDB đang làm việc để giảm các chi phí mà các giả định cũ hơn> trong các triển khai RDBMS được thực hiện nhằm hạn chế hiệu năng trong bộ nhớ thuần túy.

Giảm chi phí từ các giả định cũ hơn trong các triển khai RDBMS chính xác là mục tiêu thiết kế của VoltDB , nhưng nó có quy mô theo chiều ngang mà không có giới hạn kiến ​​trúc về kích thước dữ liệu và nó có thể duy trì độ bền của đĩa bằng cách sử dụng tính năng chụp nhanh và ghi nhật ký lệnh.

Nếu bạn có thể có một máy chủ có đủ RAM để giữ, ít nhất, phần nóng trong bộ dữ liệu của bạn, bạn sẽ ổn thôi. Ngoài ra, RAID 1 và 5 không phải là cách nhanh nhất để sắp xếp dữ liệu của bạn - RAID 0 nhanh hơn, nhưng, sau đó, bạn sẽ phải xem xét tỷ lệ cao hơn của lỗi hệ thống tệp xóa sạch cơ sở dữ liệu của bạn - không phải là một điều tốt đẹp xảy ra . Bạn có thể RAID 1 hoặc RAID 5 mảng RAID 0 của bạn, miễn là bạn có đủ ổ đĩa và bộ điều khiển.

Bạn thậm chí có thể chơi với bản sao ở đây - ghi vào máy chủ nặng đĩa, sao chép vào một hoặc nhiều máy chủ nặng bộ nhớ nơi bạn chạy các truy vấn phức tạp.

Đáng buồn thay, RDBMS dường như nằm trong vương quốc sắt lớn - chúng không dễ phát triển theo chiều ngang.

Đây là một trường hợp "nó phụ thuộc vào những gì bạn đang làm." Có lẽ lời khuyên "đúng" là tránh SQL hoàn toàn và sử dụng memcache / redis / etc!

Tôi đồng ý với bạn rằng RAM thêm sẽ giúp ích rất nhiều, đặc biệt là nếu bạn có thể đọc toàn bộ thiết lập làm việc vào RAM. Vâng, nó sẽ vẫn phải ghi dữ liệu, nhưng nếu bạn chủ yếu đọc thì ghi sẽ không có tranh chấp cho I / O đĩa.

Tuy nhiên, hiệu suất đĩa thường là một nút cổ chai trên các máy chủ SQL và khó hơn các thứ khác như RAM để nâng cấp sau này (nếu bạn có một máy chủ không được điền đầy đủ DIMM).

Có một số ý kiến ​​về RAID5 bị chậm, nhưng tôi sẽ nói rằng điều này không phải lúc nào cũng đúng, vì vậy hãy cẩn thận trước khi đưa ra các tuyên bố sâu rộng. Các máy chủ thực sự cao cấp có thẻ RAID nhanh và nhiều BBWC đôi khi đi nhanh hơn nhiều trong RAID5 (hoặc RAID50 với> 4 đĩa) so với RAID10 ...

Trong những năm qua, cá nhân tôi đã trải nghiệm các mảng RAID5 chậm, nhưng sau khi điểm chuẩn DL360 G5 với 4 đĩa 146GG vào năm 2009, chúng tôi đã phải kiểm tra lại các bài kiểm tra của mình. Thật vậy, mảng đã đi nhanh hơn với RAID5 so với RAID10 trong gần như mọi thử nghiệm. BBWC và tính toán chẵn lẻ nhanh cho phép máy chủ có thể sử dụng 4 đĩa hiệu quả hơn như một mảng RAID5 so với RAID10. Một số thử nghiệm cho thấy thông lượng tốt hơn 50% với RAID5 và gần như không có thử nghiệm nào chậm hơn. Các xét nghiệm chậm hơn chỉ giảm 5-10%.

Tôi sẽ cảnh báo những người đưa ra tuyên bố rằng RAID5 chậm, mọi người đều nói nó trực tuyến, nhưng nó đơn giản là không đúng trong mọi trường hợp.

Bạn có một túi kẹo trộn để lựa chọn và thực sự phụ thuộc vào hương vị bạn muốn là gì.

1. DB sẽ có cấu hình để truy vấn bộ đệm và nơi bộ đệm này tồn tại, bộ nhớ hoặc ổ cứng.
2. RAID 5 không phải lúc nào cũng nhanh nhất nhưng RAID 0 (JBOD) là một sọc và nhanh, vì RAID 5 cũng là một sọc nên ý tưởng cũng giống như vậy.
3. RAID 1 sẽ không cải thiện tốc độ của bạn, nó chỉ là một tấm gương.
4. Hiệu suất SQL dựa trên Lập chỉ mục và là điều đầu tiên cần kiểm tra. Rất quan trọng trong cơ sở dữ liệu quan hệ.
5. Không lập chỉ mục mọi thứ, lập chỉ mục quá mức cũng có thể làm giảm tốc độ vì lập chỉ mục của bạn trở nên quá tải.
6. Đôi khi với SQL Tham gia cơ sở dữ liệu trở nên chậm hơn. Sử dụng lập trình để lặp một tập hợp các kết quả được lập chỉ mục tối thiểu giúp cải thiện tốc độ.
7. Máy chủ ảo là một cơn ác mộng về tốc độ nếu bạn không trả đô la.

Đơn giản chỉ cần đầu tư vào kiến ​​thức (miễn phí) trước khi rút tiền mặt. 1. Tìm hiểu các cấu hình cho cơ sở dữ liệu của bạn và xem cấu hình hiện tại của bạn để tối ưu hóa. 2. Nhìn vào các câu lệnh lập trình và sql, kiểm tra đơn vị với các tập lệnh đơn giản bắt chước các hoạt động liên quan, nó thậm chí có thể không phải là những gì bạn nghĩ là vấn đề. NẾU các tập lệnh đơn giản chiếm thời gian sử dụng SQL Joins, hãy tách nó ra và làm điều tương tự với một vòng lặp được lập trình để làm tương tự. Đây là bộ nhớ có thể giúp 3. Nhìn vào kế hoạch lưu trữ và máy chủ. Sử dụng ps aux trong bảng điều khiển linux và xem liệu có thứ gì đó chiếm bộ nhớ và bộ xử lý của bạn không.

Ổ cứng tuyệt đối cải thiện tốc độ nhưng không phụ thuộc vào bạn trong không gian máy chủ ảo. Bộ nhớ không cải thiện tốc độ trừ khi bạn định cấu hình các dịch vụ cho nó, theo giai đoạn. RAID sọc (0,5), RPM và đọc / ghi đồng bộ với một bus nhanh giúp điều đó. Một bộ xử lý lõi với bộ đệm tốt l1, l2, l3 sẽ giúp xử lý nút cổ chai. Tôi có thể nghe nó cho Xeon!

Nhìn chung, bạn phải giữ kích thước và khả năng mở rộng trong tâm trí. Mặc dù bạn có thể bắt đầu với nhu cầu lưu trữ nhỏ, dữ liệu của bạn sẽ phát triển rất nhanh và theo cấp số nhân. DB là tốt nhất sử dụng dữ liệu nguyên tử, là dữ liệu được chia thành kích thước nhỏ nhất có thể. Do kích thước nhỏ, nó di chuyển nhanh hơn trong kho dữ liệu. Sau đó, bạn cũng yếu tố trong cấu trúc DB. Trong tương lai, bạn có thể liên kết với bên ngoài DB, đó là lý do tại sao cấu trúc cũng rất quan trọng. Trong trường hợp này, nó sẽ tạo ra một chút khác biệt cho truy vấn của bạn nếu một nửa dữ liệu nằm ngoài mart dữ liệu của bạn. Khi dữ liệu được truy vấn, điểm không phải là giữ dữ liệu được lưu trữ trên RAM; thay vào đó, truy vấn nên nhanh chóng trong việc truy cập và trả lại dữ liệu.

• Bạn thực sự không phải lúc nào cũng sử dụng RAID 5 cho dữ liệu. Nó phụ thuộc vào dữ liệu & tầm quan trọng của nó, bên cạnh những gì đã được đề cập trước đây về sao lưu. RAID 1 có thể được sử dụng và là.
• Bạn sẽ phải nâng cấp tất cả các máy chủ trong phạm vi truy vấn của mình để cải thiện tốc độ. Vì nhiều dữ liệu nằm ngoài tầm kiểm soát của bạn, nó sẽ bị nghẽn cổ chai ở đâu đó bên ngoài mart dữ liệu của bạn. (Trong trường hợp bạn tự nâng cấp)