用於超快速查詢的數據庫

我們有一個300 Gb +數據數組，我們想盡可能快地查詢。傳統的SQL數據庫（特別是SQL Server）不能像我們需要的那樣有效地處理這個卷（比如，在少於10秒的時間內在where子句中使用10-20個條件執行select），所以我正在調查其他解決方案來解決這個問題。用於超快速查詢的數據庫

我一直在閱讀有關NoSQL，這整個事情看起來很有希望，但我更願意聽到那些在現實生活中使用過它的人。

您能在這裏建議什麼？

編輯澄清我們之後。

我們是一家開發應用程序的公司，用戶可以通過該應用程序搜索旅遊行程並執行上述行程的預訂，並使用塑料卡支付。這整件事肯定是俄羅斯特有的，所以請耐心等待。

當用戶登錄到該網站，她呈現類似下面的形式：

alt text http://queenbee.alponline.ru/searchform.png

在這裏，用戶選擇在那裏，她從葉和她去，日期，時間和所有這一切。

點擊「搜索」後，請求會發送到我們的數據庫服務器，該服務器無法處理這種負載：查詢包括各種參數。分片也不能很好地工作。

所以我所追求的是一種僞數據庫，它可以做閃電般的查詢。

來源

2010-02-09 Anton Gogolev

如果您添加一些關於域或您正在處理的數據和查詢結構的信息，將會更容易提供有用的答案。 – nawroth 2010-02-09 18:20:50

嗨，我正面臨類似的問題，你能告訴我你用什麼來解決它嗎？ – user902383 2016-11-21 20:36:42

@ user902383交換作業:)對不起。 – 2016-11-22 06:57:03

我不知道我會同意，傳統的SQL數據庫無法處理這些卷，我可以通過這些時間範圍內更大的數據集查詢，但它已被專門用來處理這種工作，並放在合適的硬件，特別是用於處理大量數據請求的IO子系統。

來源

2010-02-09 13:46:52 Andrew

這實際上取決於您在WHERE中擁有哪些條款以及您需要什麼樣的投影數據。

這可能足以在您的表上創建適當的索引。

此外，即使擁有最佳數據結構也沒有用，因爲如果您必須每個查詢讀取100GB，因爲這也需要花費時間。

來源

2010-02-09 13:47:21

NoSQL，因爲你可能已經讀過，是不是關係數據庫。

這是一個存儲鍵值對的數據庫，您可以使用專有的API進行遍歷。

這意味着您需要自己定義數據的物理佈局，以及進行任何代碼優化。

我對此已經過時了，但幾年前我參與了一個BerkeleyDB項目，處理的數據量略少但仍然很高（約爲100Gb）。

這對我們的需要確定。

請注意，儘管對您而言可能很明顯，查詢可以進行優化。您可以發佈您在此使用的查詢嗎？

來源

2010-02-09 13:48:23 Quassnoi

NoSQL只是一個營銷術語，而不是數據庫，甚至是一種數據庫。 – 2016-04-07 23:05:33

如果您想對報告或分析進行臨時查詢，那麼最好使用可與現成報告工具搭配使用的產品。否則，你可能會發現自己總是被拖出來寫小報告程序來查詢數據。這是對NoSQL類型數據庫的罷工，但根據您的情況它可能會也可能不會成爲問題。

300GB不應該超越現代RDBMS平臺，甚至MS SQL Server的能力。這種類型的大型數據庫查詢一些其他的選項有：

看看你能不能用SSAS多維數據集和聚合，以減輕你的查詢性能問題。基於使用情況的優化可以讓您獲得足夠的性能，而無需獲得其他數據庫系統。 SSAS還可以用於無共享配置，允許您在具有直連磁盤的相對便宜的服務器集羣中劃分查詢條帶。如果你這樣做，請看ProClarity的前端。
Sybase IQ是一種RDBMS平臺，它使用針對報表查詢進行優化的底層數據結構。它的優點是它可以很好地與各種常規報告工具搭配使用。還有其他幾種這種類型的系統，如Red Brick，Teradata或Greenplum（它使用PostgreSQL的修改版本）。對這些系統的主要打擊是它們並不是完全大衆化的產品，而且可能相當昂貴。
Microsoft在管道中有一個無共享版本的SQL Server，您可能可以使用該版本。但是他們已經將它與第三方硬件製造商聯繫在一起，因此您只能使用專用（因此昂貴）的硬件才能獲得它。
尋找機會利用匯總數據構建數據集市以減少某些查詢的數量。
看看調整你的硬件。直接連接SAS陣列和RAID控制器可以很快地完成表掃描中使用的流式I/O。如果您通過大量鏡像對對錶進行分區，您可以獲得非常快的流式處理性能 - 可輕鬆飽和SAS通道。

實際上，如果您需要所描述的性能目標，那麼您希望從I/O子系統獲得10-20GB /秒的速度，並且無需訴諸真正特殊的硬件就可以做到這一點。

來源

2010-02-09 13:55:14 ConcernedOfTunbridgeWells

從我瞭解的很少，傳統的RDBMS是基於行優化的插入速度。但是，基於列的存儲系統可以最好地實現檢索速度優化。

有關更詳盡的說明，請參見Column oriented DBMS比我可以給

來源

2010-02-09 14:00:08

一個正確設置SQL服務器應該能夠處理在T字節數據，而不必性能問題。我有幾個管理SQl服務器數據庫的朋友，他們的大小沒有性能問題。

您的問題可能是一個或更多的這些：

不足的服務器規格
缺乏好的分區
可憐的索引
可憐的數據庫設計
可憐的查詢設計包括使用的像LINQ這樣的工具可能會寫表現不佳的代碼爲數據庫大小。

它確實不是SQL Server處理這些負載的能力。如果你有一個數據庫的規模，你需要聘請一個專業的dba，在優化大型系統方面有豐富的經驗。

來源

2010-02-09 14:46:08 HLGEM

+1肯定需要員工/人員進行高端處理。 – Andrew 2010-02-09 15:05:19

我希望一個「常規」數據庫可以做你想做的事情，只要你適當地爲你正在做的查詢構造你的數據。

您可能會發現，爲了可生成報告，您需要彙總生成（或加載，轉換等）數據並彙總彙總數據。

SELECT的速度與WHERE子句中的條件數（通常）無關（大多數情況下直接），但它與解釋計劃和檢查的行數有關。有些工具會爲你分析這個。最終，在300G（這不是那麼大）時，您可能需要至少在某些時間將某些數據保留在磁盤上（=慢），因此您希望開始減少所需的IO操作數。減少IO操作可能意味着使用不同的聚簇索引來覆蓋索引，彙總表和數據副本。這讓你的300G變大了，但是誰在乎。

IO OPS是王:)

顯然做這些事情是非常昂貴的開發時間方面，所以你應該在這個問題拋出大量硬件的啓動，只有嘗試與軟件一旦修復變得不足。大量的RAM是一個開始（但它不能以當前的成本效益水平一次性存儲> 10-20％的數據集）。即使SSD近來也不是那麼昂貴。

來源

2010-02-10 07:50:36 MarkR

用於超快速查詢的數據庫

回答

相關問題