我們業務問題之一的解決方案是將大約500萬條記錄存儲到數據庫中。 每個記錄將有大約40到50列。大型數據庫500萬條記錄
我有一個包含所有這些數據的文本文件，大約150 GB。 （我的硬盤的第三個）
如果我要加載（以某種方式）所有這些數據到一個數據庫（ORACLE？）它的性能如何？
我的一位同事堅持認爲這絕對沒問題。 我甚至可以將所有40到50列索引，然後編寫一些sql來獲取數據。
他對嗎？ 或者500萬記錄對於db來說太多了？
p.s. 只需在以下一些非常好的答案中添加更多信息： 40至50列將包含小字符串和/或數字。 對於小字符串，我打算使用小於64個字符的東西。
沒有任何關於您正在使用的關係數據庫管理系統的信息，它是如何託管的，以及這是什麼類型的數據（大文本，小數字等），一個可靠的答案並不容易。
純數量的記錄不應該是一個問題，幾乎每個現代RDBMS都可以輕鬆處理5億條記錄和更多記錄。
數據存儲在RDBMS上會變得更有趣，p.e.它使用的是什麼類型的文件系統，表格有多少可用磁盤空間，表格是如何分佈在硬盤上的等等，這些都應該被考慮。
一般來說，我建議只索引應用程序真正需要的列和數據用於查詢的列，否則它們只會減慢插入速度，使用珍貴的磁盤空間並根本沒有任何幫助。
這裏有幾個SO鏈接這可能會幫助您進一步：
你的同事是正確的 - 數據庫中的500萬條記錄是好的，我用了2G行的數據庫，這是10年前。對每一列進行索引是一個問題 - 索引會減慢每一個新的記錄插入，並且構建索引需要花費很長時間。您需要確定要運行哪種查詢，然後進行適當的索引。有了這麼多的記錄，你可以通過規範化數據來獲得好處 - 平面結構往往更快，但是如果你有重複的長文本字段，那麼用查找替換它們可能會給存儲和索引帶來好處。在沒有看到數據的情況下，很難提供更精確的建議。
順便說一句如果你打的性能probs你也可以將數據劃分到物理上分離的表，也許按年？
我的下一步（選擇數據庫平臺並找到服務器後）是加載數據並查看它的執行情況。我會看看批量加載你的數據 - 我是一個Sql服務器小組，因此Integration Services是要走的路。我會確保你有一個唯一的鍵，如果它不在數據中添加一個標識列。那麼你準備好測試一下了。 SqlExpress是免費的，帶有SSIS，但它只能處理10G數據庫 - 但這足以熟悉這些問題。
我經常批量裝載一個4列的行，列數超過50列，大約需要2分鐘。如果您希望獲得更進一步的建議，我很樂意將其脫機。