Vertica for non-analytics

Question

我在我的系統中有一個大的分析模塊，並計劃使用vertica。 有人建議我們在我們的應用程序的其餘部分（標準crud應用程序與我們的域中的模型）中使用vertica，以免管理多個數據庫。

vertvertica是否適合這種雙重場景？

Answer 1

這些日子通常是這樣，一個有意義的答案取決於你需要做什麼。從一般意義上說，「大數據」解決方案已經從RDBMS系統中的大數據量缺陷發展而來。沒有「大數據」解決方案可以與RDBMS系統的核心功能（即複雜分析）競爭，但RDBMS系統是大數據量處理的差（昂貴）解決方案。現在實用的解決方案必須是混合解決方案。一旦數據加載完成，Vertica可能會很好，但我相信（不是專家），它需要數據的非規範化和預加載前的預先排序才能達到最佳效果。對於大數據量，這可能會顯着增加所需的資源。使用一個系統滿足您的所有需求是一個明顯的好處，但保持選項開放也有好處。

我採取的方法是存儲和索引新數據，然後根據需要爲各種報告/分析引擎提供特定的供稿。這將原始數據的收集和存儲與複雜的分析處理分開。如果您有興趣，我很樂意提供更多細節。這種分離解決了數據庫系統中一直存在的核心問題。在過去，您曾經聽過'快速存儲，慢速報告或緩慢存儲，快速報告，但不能同時存在'。在過去的幾年中，搜索完整的解決方案產生了許多通常解決「快速存儲」任務的NoSQL產品。有些系統還通過將數據存儲在內存或緩存中提供令人印象深刻的查詢性能，但這需要很多服務器來處理大量數據。我相信NoSQL和SQL解決方案可以並且將會被整合，但這是直到現在。

爲了給您提供一些背景知識，我使用了每天至少加載10億條記錄的場景。如果您每天處理1億條記錄（大是相對的），那麼您的Vertica方法可能就足夠了，否則我認爲您需要擴展您的選項。

Answer 2

高頻率更新可能是Vertica滯後最糟糕的地方。我會避免將它用於這種數據模型。

Answer 3

亞歷克 - 我想尊重您對Vertica的評論。在加載之前，您不需要對數據進行非規範化或排序。 Vertica還擁有在所有數據庫中加載數據速度最快的記錄。

您還談到了Vertica無法執行復雜分析以及RDBMS。 Vertica是一個RDBMS，可以比其他任何RDBMS更快地進行分析，並且它們一遍又一遍地證明它。

就您的數字而言，在我的使用案例中，我每秒向我的Vertica羣集中加載大約500萬條記錄，並擁有數百億記錄。

So Yaron - 我強烈建議您在Vertica基於此信息排除之前查看Vertica。

Answer 4

測試它。每個用例都不相同。假設Vertica是每個用例的解決方案，與使用MongoDB for every use case幾乎一樣糟糕。

Vertica是一款高性能分析數據庫，專門用於分析難以置信的大數據集和水平縮放。它也很昂貴，很難管理，而且文檔很少見。在合適的環境中獲得回報可能很容易，值得工作，MySQL是一種傳統的面向行的RDBMS，旨在建模結構化數據之間的關係，並且在單個節點規模上運行良好（儘管許多公司已對其進行了改進取得巨大成功，模範特惠，Facebook）。它的記錄非常好，看起來可以在任何平臺，語言或框架上運行，並且可以被任何人使用。

我的猜測是使用Vertica作爲員工地址簿數據庫，就像是在3000美元的套裝中顯示藍領工作。當然，它工程，但它是工作的正確工具？也許如果您已經擁有Vertica許可證，並且您的應用程序已經具備必要的數據適配器/ ORM /等...，請繼續並嘗試一下。它仍然是一個SQL數據庫，所以它應該在這些情況下正常工作。如果您的目標是最小編程而不是最佳性能，那麼爲什麼要使用Vertica？聽起來更簡單會更理想。 Vertica可能會或可能不會在常規的CRUD應用程序環境中提供更好的性能，因爲它沒有針對此優化進行優化，但您可以隨時測試並查看。

Answer 5

Vertiy有很多高併發問題（每分鐘很多小事務） 在MPP系統中，數據在整個羣集中被分段，每當需要進行羣集級鎖定時（主要是在提交時間內）提交了許多集羣級別的X鎖。 高併發性不如DWH和報告中的用例，因此vertica非常適合這種情況。 在大多數情況下OLTP解決方案，爲客戶提供高併發性已很是不錯的選擇

感謝