『壹』 十萬人名單儲存在電腦里需要多大內存
十萬人名單儲存在電腦里需要500G內存我們都知道1G等於1024mB。現在我們比較常見的話，一張照片大約在5mb左右，那麼10張50MB，100張500MB，1000張等於5000MB(5g)。1萬張等於50000MB(50g)，10萬張就等於50萬MB(500g)，表面上看500G的硬碟就夠了，但實際500g的硬碟在電腦上的演算法並不是說1g等於1024MB算的。
內存大的優勢
主要是在多任務的情況下速度要快些，內存實際上就是一塊臨時是有存儲空間，每一個軟體在運行的時候都要來劃一塊，所以如果內存比較小的話，運行幾個程序後再運行一個程序它們就要搶內存了，也就是說此時的內存已經嚴重的影響了機子的速度，但是如果內存足夠大的話，這個問題很明顯就不會出現了。
『貳』 200億條數據需要多大存儲
2TB。200億條數據需要2TB存儲，數據(data)是事實或觀察的結果，是對客觀事物的邏輯歸納，是用於表示客觀事物的未經加工的的原始素材。
『叄』 多大的數據，才能稱為大數據呢
5. Veracity（真實性）
大數據就一定真實么？並沒有。為什麼這么說呢，想像一下當下泛濫的作弊流量吧，你還敢確保你的用戶數據並沒有虛假的嗎？所以，大數據也是可以造假的，我們一定要有一雙智慧的眼睛卻辨別大數據的好壞。
不知道你說的一般內容 是什麼內容 如果有很多Text或者varchar(5000) 那容量也就難算了。
一般來說 百萬條記錄可以初略算一下
假設一條記錄平均佔用 1kb 那麼一百萬記錄大致需要
1kb * 1000 *1000 約＝ 1G
『伍』 我存大數據需要多大容量硬碟合適
基本都是2T4T的移動硬碟，看個人儲存需要的數據有多大，還有個人的經濟預算。
『陸』 千萬級數據
資料庫吧，你用什麼資料庫
mysql可以配合lucene做搜索引擎，還不夠大可以用cluster.一般你用like沒問題，索引要做得好。
如果大家有異議，可以在後面補充。我會隨時更新的。
現在大概列出如下:(望各位補充)
1.資料庫的設計
盡量把資料庫設計的更小的占磁碟空間.
1).盡可能使用更小的整數類型.(mediumint就比int更合適).
2).盡可能的定義欄位為not null,除非這個欄位需要null.（這個規則只適合欄位為KEY的情形）
3).如果沒有用到變長欄位的話比如varchar,那就採用固定大小的紀錄格式比如char.（CHAR 總是比VARCHR快）
4).表的主索引應該盡可能的短.這樣的話每條紀錄都有名字標志且更高效.
5).只創建確實需要的索引。索引有利於檢索記錄，但是不利於快速保存記錄。如果總是要在表的組合欄位上做搜索，那麼就在這些欄位上創建索引。索引的第一部分必須是最常使用的欄位.如果總是需要用到很多欄位，首先就應該多復制這些欄位，使索引更好的壓縮。
（這條只適合MYISAM引擎的表，對於INNODB則在保存記錄的時候關系不大，因為INNODB是以事務為基礎的，如果想快速保存記錄的話，特別是大批量的導入記錄的時候）
6).所有數據都得在保存到資料庫前進行處理。
7).所有欄位都得有默認值。
8).在某些情況下,把一個頻繁掃描的表分成兩個速度會快好多。在對動態格式表掃描以取得相關記錄時，它可能使用更小的靜態格式表的情況下更是如此。
(具體的表現為：MYISAM表的MERGE類型，以及MYISAM和INNODB通用的分區，詳情見手冊)
9).不會用到外鍵約束的地方盡量不要使用外鍵。
2.系統的用途
1).及時的關閉對MYSQL的連接。
2).explain 復雜的SQL語句。（這樣能確定你的SELECT 語句怎麼優化最佳）
3).如果兩個關聯表要做比較話，做比較的欄位必須類型和長度都一致.（在數據龐大的時候建立INDEX）
4).LIMIT語句盡量要跟order by或者 distinct.這樣可以避免做一次full table scan.
5).如果想要清空表的所有紀錄,建議用truncate table tablename而不是delete from tablename.
不過有一個問題，truncate 不會在事務處理中回滾。因為她要調用create table 語句。
（Truncate Table 語句先刪除表然後再重建，這個是屬於文件界別的，所以自然快N多）
實測例子：
song2為INNODB表。
mysql> select count(1) from song2;
+----------+
| count(1) |
+----------+
| 500000 |
+----------+
1 row in set (0.91 sec)
mysql> delete from song2;
Query OK, 500000 rows affected (15.70 sec)
mysql> truncate table song2;
Query OK, 502238 rows affected (0.17 sec)
mysql>
{
這一點手冊上有詳細解釋：
13.2.9. TRUNCATE語法
TRUNCATE [TABLE] tbl_name
TRUNCATE TABLE用於完全清空一個表。從邏輯上說，該語句與用於刪除所有行的DELETE語句等同，但是在有些情況下，兩者在使用上有所不同。
對於InnoDB表，如果有需要引用表的外鍵限制，則TRUNCATE TABLE被映射到DELETE上；否則使用快速刪減（取消和重新創建表）。使用TRUNCATE TABLE重新設置AUTO_INCREMENT計數器，設置時不考慮是否有外鍵限制。
對於其它存儲引擎，在MySQL 5.1中，TRUNCATE TABLE與DELETE FROM有以下幾處不同：
· 刪減操作會取消並重新創建表，這比一行一行的刪除行要快很多。
· 刪減操作不能保證對事務是安全的；在進行事務處理和表鎖定的過程中嘗試進行刪減，會發生錯誤。
· 被刪除的行的數目沒有被返回。
· 只要表定義文件tbl_name.frm是合法的，則可以使用TRUNCATE TABLE把表重新創建為一個空表，即使數據或索引文件已經被破壞。
· 表管理程序不記得最後被使用的AUTO_INCREMENT值，但是會從頭開始計數。即使對於MyISAM和InnoDB也是如此。MyISAM和InnoDB通常不再次使用序列值。
· 當被用於帶分區的表時，TRUNCATE TABLE會保留分區；即，數據和索引文件被取消並重新創建，同時分區定義（.par）文件不受影響。
TRUNCATE TABLE是在MySQL中採用的一個Oracle SQL擴展。
}
6).能使用STORE PROCEDURE 或者 USER FUNCTION的時候.（ROUTINE總是減少了伺服器端的開銷）
7).在一條insert語句中採用多重紀錄插入格式.而且使用load data infile來導入大量數據，這比單純的indert快好多.（在MYSQL中具體表現為：INSERT INTO TABLEQ VALUES (),(),...();）
（還有就是在MYISAM表中插入大量記錄的時候先禁用到KEYS後面再建立KEYS,具體表現語句：
ALTER TABLE TABLE1 DISABLE KEYS;ALTER TABLE TABLE1 ENABLE KEYS;
而對於INNNODB 表在插入前先 set autocommit=0;完了後：set autocommit=1;這樣效率比較高。）
8).經常OPTIMIZE TABLE 來整理碎片.
9).還有就是date 類型的數據如果頻繁要做比較的話盡量保存在unsigned int 類型比較快。
3.系統的瓶頸
1).磁碟搜索.
並行搜索,把數據分開存放到多個磁碟中，這樣能加快搜索時間.
2).磁碟讀寫(IO)
可以從多個媒介中並行的讀取數據。
3).CPU周期
數據存放在主內存中.這樣就得增加CPU的個數來處理這些數據。
4).內存帶寬
當CPU要將更多的數據存放到CPU的緩存中來的話,內存的帶寬就成了瓶頸.
====
Another article more about tuning details:
http://www.informit.com/articles/article.aspx?p=29406&seqNum=1
http://blog.chinaunix.net/u/29134/showart_264480.html
『柒』 sql server需要存儲1000萬條數據該怎麼辦
以現在的技術，有下面的提示給你：
一、配置為：雙CPU（四核）/RAID5陣列硬碟 的當前的典型數據伺服器，可以存儲每條數據長度不是過大的1000萬條以上數據。
二、存儲是一回事，處理好數據是另一回事，如果對這千萬條數據，在做好關鍵欄位的索引後，只是存儲和查詢的話，速度不會太慢，一般最多幾秒內能給出查找結果。
三、但是，如果你要對這千萬條數據進行分組匯總之類的操作的話，那就很麻煩了，可能慢到你無法接受，甚至會給出超時等報錯的提示。解決的辦法是，優化查詢語句，進行存儲過程的合理編寫。
四、千萬條數據一般會使得資料庫文件的體積達到幾十G甚至更多。
『捌』 能夠存儲的數據量一般有多大
1.資料庫的大小限制：SQL Server 2005 Express 和SQL Server 2008 Express
資料庫的大小限制最大為 4GB，最新版本的SQL Server 2008 R2 Express 資料庫的大小限制最大為
10G。這個大小的限制只有在數據文件上，事務日誌大小則不受此限。
2.只能使用一個 CPU 來運算，這在多個 CPU 的電腦上會造成浪費。
3.可使用的存儲器量最高只有 1GB。
4.沒有 SQL Agent，若要做調度服務必須自己寫程序。
『玖』 互聯網如何海量存儲數據
目前存儲海量數據的技術主要包括NoSQL、分布式文件系統、和傳統關系型資料庫。隨著互聯網行業不斷的發展，產生的數據量越來越多，並且這些數據的特點是半結構化和非結構化，數據很可能是不精確的，易變的。這樣傳統關系型資料庫就無法發揮它的優勢。因此，目前互聯網行業偏向於使用NoSQL和分布式文件系統來存儲海量數據。
下面介紹下常用的NoSQL和分布式文件系統。
NoSQL
互聯網行業常用的NoSQL有：HBase、MongoDB、Couchbase、LevelDB。
HBase是Apache Hadoop的子項目,理論依據為Google論文 Bigtable: A Distributed Storage System for Structured Data開發的。HBase適合存儲半結構化或非結構化的數據。HBase的數據模型是稀疏的、分布式的、持久穩固的多維map。HBase也有行和列的概念，這是與RDBMS相同的地方，但卻又不同。HBase底層採用HDFS作為文件系統，具有高可靠性、高性能。
MongoDB是一種支持高性能數據存儲的開源文檔型資料庫。支持嵌入式數據模型以減少對資料庫系統的I/O、利用索引實現快速查詢，並且嵌入式文檔和集合也支持索引，它復制能力被稱作復制集（replica set），提供了自動的故障遷移和數據冗餘。MongoDB的分片策略將數據分布在伺服器集群上。
Couchbase這種NoSQL有三個重要的組件：Couchbase伺服器、Couchbase Gateway、Couchbase Lite。Couchbase伺服器，支持橫向擴展，面向文檔的資料庫，支持鍵值操作，類似於SQL查詢和內置的全文搜索;Couchbase Gateway提供了用於RESTful和流式訪問數據的應用層API。Couchbase Lite是一款面向移動設備和「邊緣」系統的嵌入式資料庫。Couchbase支持千萬級海量數據存儲
分布式文件系統
如果針對單個大文件，譬如超過100MB的文件，使用NoSQL存儲就不適當了。使用分布式文件系統的優勢在於，分布式文件系統隔離底層數據存儲和分布的細節，展示給用戶的是一個統一的邏輯視圖。常用的分布式文件系統有Google File System、HDFS、MooseFS、Ceph、GlusterFS、Lustre等。
相比過去打電話、發簡訊、用彩鈴的「老三樣」，移動互聯網的發展使得人們可以隨時隨地通過刷微博、看視頻、微信聊天、瀏覽網頁、地圖導航、網上購物、外賣訂餐等，這些業務的海量數據都構建在大規模網路雲資源池之上。當14億中國人把衣食住行搬上移動互聯網的同時，也給網路雲資源池帶來巨大業務挑戰。
首先，用戶需求動態變化，傳統業務流量主要是端到端模式，較為穩定；而互聯網流量易受熱點內容牽引，數據流量流向復雜和規模多變：比如雙十一購物狂潮，電商平台訂單創建峰值達到58.3萬筆，要求通信網路提供高並發支持；又如優酷春節期間有超過23億人次上網刷劇、抖音拜年短視頻增長超10倍，需要通信網路能夠靈活擴充帶寬。面對用戶動態多變的需求，通信網路需要具備快速洞察和響應用戶需求的能力，提供高效、彈性、智能的數據服務。
「隨著通信網路管道十倍百倍加粗、節點數從千萬級逐漸躍升至百億千億級，如何『接得住、存得下』海量數據，成為網路雲資源池建設面臨的巨大考驗」，李輝表示。一直以來，作為新數據存儲首倡者和引領者，浪潮存儲攜手通信行業用戶，不斷 探索 提速通信網路雲基礎設施的各種姿勢。
早在2018年，浪潮存儲就參與了通信行業基礎設施建設，四年內累計交付約5000套存儲產品，涵蓋全快閃記憶體儲、高端存儲、分布式存儲等明星產品。其中在網路雲建設中，浪潮存儲已連續兩年兩次中標全球最大的NFV網路雲項目，其中在網路雲二期建設中，浪潮存儲提供數千節點，為上層網元、應用提供高效數據服務。在最新的NFV三期項目中，浪潮存儲也已中標。
能夠與通信用戶在網路雲建設中多次握手，背後是浪潮存儲的持續技術投入與創新。浪潮存儲6年內投入超30億研發經費，開發了業界首個「多合一」極簡架構的浪潮並行融合存儲系統。此存儲系統能夠統籌管理數千個節點，實現性能、容量線性擴展；同時基於浪潮iTurbo智能加速引擎的智能IO均衡、智能資源調度、智能元數據管理等功能，與自研NVMe SSD快閃記憶體檔進行系統級別聯調優化，讓百萬級IO均衡落盤且路徑更短，將存儲系統性能發揮到極致。
「為了確保全球最大規模的網路雲正常上線運行，我們聯合用戶對存儲集群展開了長達數月的魔鬼測試」，浪潮存儲工程師表示。網路雲的IO以虛擬機數據和上層應用數據為主，浪潮按照每個存儲集群支持15000台虛機進行配置，分別對單卷隨機讀寫、順序寫、混合讀寫以及全系統隨機讀寫的IO、帶寬、時延等指標進行了360無死角測試，達到了通信用戶提出的單卷、系統性能不低於4萬和12萬IOPS、時延小於3ms的要求，產品成熟度得到了驗證。
以通信行業為例，2020年全國移動互聯網接入流量1656億GB，相當於中國14億人每人消耗118GB數據；其中春節期間，移動互聯網更是創下7天消耗36億GB數據流量的記錄，還「捎帶」打了548億分鍾電話、發送212億條簡訊……海量實時數據洪流，在網路雲資源池(NFV)支撐下收放自如，其中分布式存儲平台發揮了作用。如此樣板工程，其巨大示範及拉動作用不言而喻。