我的任務是實施/重新設計一種解決方案，該解決方案將儲存來自感測器陣列的天氣數據。該陣列將由約 40 個塔組成，每個塔都有約 10 個感測器，每個感測器將以 10 秒的間隔對大氣條件進行採樣，時間不確定（年）。該任務的一些應用和要求如下：

• 管理和檢索塔/感測器配置以進行數據分析。
• 通過感測器或時間間隔進行氣象觀測的數據視覺化。
• 為客戶提供可靠且持久的數據資源/數據集，以比較模型和感測器的性能（可能需要一些後處理才能以所需的格式傳遞？）。

注意：目前解決方案（作為概念驗證實施，有 5 個塔）將數據儲存為平面文件（每小時一個文件）。

我最初不確定這是否會構成未來的大數據問題，所以我研究了一些關係數據庫和 NoSQL 數據庫的解決方案，但我覺得我需要更多的指導，因為我不是數據管理方面的專家。

我認為的解決方案之一是將數據儲存在由塔、感測器和時間戳索引的關係數據庫中，並按日期對錶進行分區。

另一種是基於未來的擴展，將其儲存在文件類型的 NoSQL 數據庫中，如 MongoDB，並模仿目前解決方案的結構。

這些有什麼好的方法嗎？如果沒有，什麼是更好/推薦的解決方案？此外，是否有必要重新設計目前的解決方案？有人告訴我，使用平面文件的理由是他們認為關係數據庫會佔用太多成本。如果是這種情況，有沒有辦法避免這種情況？

由於（a）您正在使用的資訊本身似乎是一種非常有價值的組織資源，並且（b）數據量將相當可觀，因此我決定（c）在其中一個上建構一個關係數據庫主要的 SQL 平台。

當然——從一個非常普遍的角度來看——需要三個基本因素：

1. 一個明確定義的概念模式，其中必須準確地辨識和標記事物的原型，即與您正在使用**的業務環境（例如，塔和你提到的感測器）。

如您所知，這一點需要與業務專家建立持續且富有成效的溝通。 2. 準確反映概念級別的邏輯佈局，通過表格（即數學關係）保存具有適當列名稱和類型（即關係屬性）的良好分隔列以及所有相應的**約束，以確保數據符合上一層確定的所有規則。

因此，正是在這裡，關係模型的巨大力量發揮了作用（儘管它的優勢在其他抽象層次上產生了積極的影響）。 3. 一種物理佈置，例如，提高“動態”邏輯數據操作操作的執行速度並保證邏輯約束。

由於關係模型提供物理數據獨立性，因此數據庫管理系統（簡稱 DBMS）可以在此級別提供任何類型的結構，而不僅僅是索引，以支持邏輯定義。在領先的 SQL 平台的情況下，是的，這通常意味著，準確地說，根據特定於數據庫的查詢趨勢設置索引策略，並且您對一些可能的配置提出了非常有趣的考慮，但不知道具體的準確的資訊必需品，在這方面提供具體建議是不合適的。

其他值得評估的因素包括，例如昇級網路基礎設施以增加頻寬、啟用適當的伺服器配置（硬體和軟體方面）等。而且，當且僅當從業者足夠合格時，他或她甚至可以修改所選 DBMS 的原始碼（在開源環境中自然更可行）。

這樣，您突出顯示的以下方面

• 管理和檢索塔/感測器配置以進行數據分析。
• 通過感測器或時間間隔進行氣象觀測的數據視覺化。
• 為客戶提供可靠且持久的數據資源/數據集，以比較模型和感測器的性能（可能需要一些後處理才能以所需的格式傳遞？）。

將得到很好的解決，因為您可以輕鬆地聲明查詢，例如，以非常有意義的形式獲取資訊。例如，您可以獲取與

• *由 SensorNumber 標識的 Sensor 1750，安裝在由 TowerNumber 標識的 Tower 上31，位於 Date1 June 2017和 Date27 June 2017*之間。

此外，由於 (1) 關係數據庫中的數據在基於關係代數的操作的幫助下按照集合進行邏輯管理，並且 (2) 不同的 SQL 引擎針對集合進行了物理優化（比其他引擎多一些）處理，你可以，例如，

• 將集合a與集合b進行比較；
• 將集合c與集合d連接；
• 通過對集合e的限制獲得子集合**f；
• 從n 個集合交點產生n個子集；
• 項目集f中的**n 個屬性
• 從集合z中檢索資訊，該資訊是集合x與集合y的並集的結果；
• 等等。

數據操作的可能性實際上是巨大的——證明了關係範式無與倫比的多功能性——因為您不僅可以使用基表（用CREATE TABLE … ( … );語句聲明的表），還可以使用派生表（通過SELECT …;操作表示的表，有時固定為VIEWs） . 換句話說，您可以 (i)基於 (ii) 在 (iii) 單個基礎關係構造（即數學關係）上執行的先前資料結構來表達新的資料結構。

顯然，關係數據庫的基表和列的排列可以演變，並且 (a) 當 (b) 跟踪新的實體類型或實體類型屬性被認為值得時，可以將新的基表或列合併到其中。相關的業務環境。換句話說，關係數據庫的初始結構和開放約束都不應該是靜態的或不可變的*。*此外，當出現新的資訊需求時，從一開始就適當組織的數據庫往往更容易修改。

與上述考慮一致，適用集的邏輯格式必須在數據庫邏輯級別以聲明方式生成。集合的圖形或表示格式（例如，使用的顏色或字型）必須依次通過一個或多個應用程序的程式碼進行處理（是的，主要以程序方式，也許在對象的幫助下面向的框架、HTML 等），以使此類集合的訪問和呈現對使用者友好。當然，您也可以使用與您的數據庫連接的報告軟體。

相關性數據庫的建模

鑑於您將使用感測器數據（除其他功能外，這些數據通常涉及時間序列形式的資訊），您可能會在@PerformanceDBA的兩個特殊答案中找到對多個數據庫設計和總體管理原則的幫助，題為：

• “關於感測器/讀取/警報數據庫設計的意見”，以及
• “歷史/可審計的數據庫”。

關係、平面文件和 NoSQL 方法

Edgar Frank Codd 博士的關係模型雖然發表於 1970 年，但仍然是處理數據管理問題的真正最現代和最優雅的方法（基於邏輯和集合論）。反過來，不同的 SQL DBMS 是關係理論中提出的系統最流行的近似（雖然不完全兼容，但仍然非常強大），其中一些已經過大量優化（例如，關於它們的物理-水平機制）甚至幾十年。此外，主要的 SQL 平台當然可以（並且將能夠）非常有效地使用最新的儲存（例如，硬碟驅動器）和處理（例如，CPU）技術。

當建立在強大的 DBMS 之上時，在概念、邏輯和物理級別上進行適當設計的關係數據庫無疑將成為一種自包含、自描述和自保護的資產，它 (1) 是值得信賴的並且 (2) 提供了快速響應，如您所知，這兩個方面具有重要意義。

平面文件

因此，以下主張

有人告訴我，使用平面文件的理由是他們認為關係數據庫會佔用太多成本。

很容易被丟棄，因為平面文件方法是：

• 前科學;
• 對於大量數據來說遠非最佳；
• 太麻煩了；
• 依賴於應用程序（並且您必須手動實現適當的 DBMS 原生提供的大多數功能）；
• 它的性能很容易受到破壞；
• 等等。

而——更方便的——關係方式，至少可以這麼說：

• 將提供較大的可擴展性（它與物理級別無關，因此您可以根據需要增強底層物理機制）；
• 將帶來一種簡單的風格來操縱數據（通過抽像操作）和
• 可以同時與多個應用程序一起工作（例如，一個或多個移動應用程序，和/或一個或多個網路應用程序，和/或一個或多個桌面應用程序等）。

但是，如果您選擇使用平面文件，您應該評估像Awk這樣強大的實用程序的使用情況，儘管它不是 DBMS（並且不是這樣設計的），但它提供了方便的資源來處理文件、記錄、欄位等. 有關此主題的更多資訊，請參閱GNU Awk 使用者指南。

NoSQL

“非結構化數據”和相關術語

根據他們的宣傳，使用 NoSQL DBMS 的最初理由是它們旨在用於涉及處理“非結構化數據”的業務領域，因此需要提出以下問題：

• “非結構化數據”應該是什麼意思？

在這方面，必須說數據就其本質而言是結構化的；如果它沒有結構，那麼它將是毫無意義的東西，因此這樣的東西 (i)不能被視為數據，並且 (ii)不值得管理。因此，“非結構化數據”是一個矛盾和不幸的表述。

這些上下文的其他片語是“半結構化數據”。該片語表明存在“部分”或“一半”結構化的數據，因此根據上一段，只有結構化的“部分”或“一半”可以是實際數據，其餘的“部分”或者“一半”只是一個無形的東西，因為它缺乏結構，不能稱為數據。

唉，在 NoSQL 行銷中發現的另一個典型術語是“多態數據”。如果該術語表示“具有多種不同形式的數據”之類的東西，那麼它實際上是普通數據，它一如既往地以多種不同的形式出現。而且由於它有很多不同的形式，所以它呈現出很多不同的結構，所以這種“類型”的數據並沒有什麼特別之處。

不用說，數據和資料結構一直很容易發生變化，那麼這方面也沒有什麼不尋常的。

數據量增長

顯然，通過電腦化系統管理的資訊量多年來肯定在增長——並且隨著時間的推移將繼續呈指數增長，因為每天都在建構新系統——但這與事實無關資訊本身的結構。

缺乏全面的理論基礎

NoSQL 系統的一個關鍵限制（有不同的類別，例如，基於文件和圖形）是目前的產品——儘管大量銷售並被標記為“現代”——都沒有一個健全的理論基礎（如果有的話）它支持適當的 DBMS 的三個最重要元素中的每一個，即用於數據 (a) 定義、(b) 操作和 (c) 收縮的工具。因此，NoSQL 方法實際上暗示了一種對古代時代的回歸，在該時代中，數據處理是在一個臨時的和不健全的行動過程中執行的，它帶來了所有不必要的複雜性。

如今，圖系統已包含在“NoSQL”範圍內。這些軟體產品通過對兩種不同結構的操作來管理數據：節點和關係——這再次與術語“非結構化數據”相衝突——它們在“NoSQL”組中脫穎而出，因為它們確實有數學基礎。然而，圖形產品與網路平台非常相似，幾十年前就被認為已經過時（一個明顯的缺點是，如上所述，它們需要兩種結構來表示數據，而關係 DBMS——根據**資訊原則——只需要一個）。

即使與大多數 SQL DBMS 的起源相比，不同 NoSQL 系統的創建按時間順序更新，但 NoSQL 產品所基於的大多數概念實際上都是原始的。

NoSQL 程序應該主要用於以下場景：

• IT 人員缺乏確定（或適時確定）感興趣數據的結構所需的技術技能——例如，由於其複雜性——；和/或
• 該組織無法為現有工作人員提供適當的教育和培訓，或無法僱用具備所需教育和培訓的新員工；和/或
• 當數據的完整性和一致性不是特別重要時；和/或
• 當將相關數據與要求高精度的關鍵任務系統的數據混合時，是不可預料的。

但是，即使在創建相關係統之前未定義相關數據的結構，也必然需要一個或多個人

• 發現上述結構，
• 丟棄所有周圍的“干擾”和
• 收集並連結適當的數據

在數據庫和應用程序進入生產階段之後，為了能夠最大限度地利用投入到項目中的所有資源，那麼資料結構描繪是一項無法繞過的任務，必須盡快完成或更晚。

因此，雖然採用 NoSQL 方式是可能的，但前面提到的所有因素都絕對應該考慮在內。

最穩健的方法

相比之下，以關係的方式處理業務環境的資訊需求——即，背後有一個通用範式——提供了以下可能性：（1）從一開始就以自然結構管理數據——這有助於與其他數據源的集成——以及（2）通過操縱單一儀器（如前幾節所述）產生新的可信賴結構，該儀器具有強大的科學基礎。

根據您對相關場景的描述，您已經根據相關的組織需求確定了一個特定的結構，因此我建議您請業務領域專家對其進行驗證。接下來，我建議利用 (i) 關係模型提供的構造（關係、約束和操作）來處理所述結構和相應的數據，以及 (ii) 您選擇的 SQL DBMS，這很可能提供非常有效的物理工具，可以滿足目前的需求並提供未來的可擴展性。

引用自：https://dba.stackexchange.com/questions/177332