我需要存儲大約10萬個代表用戶的對象。這些用戶擁有用戶名，年齡，性別，城市和國家。（Java）存儲大量帶有索引屬性的對象集合
用戶應該是可搜索的一系列年齡和任何其他屬性，但也是屬性的組合（例如布魯塞爾30至35歲之間的女性）。結果應該很快找到，因爲它是許多連接客戶端的服務器服務之一）。用戶只能被刪除或添加，而不能更新。
我想過用索引的屬性快速的數據庫（如H2 DB這似乎是相當快的，我已經看到他們有一個內存模式）
我想知道是否有任何其他選項在去DB之前是可以的。
謝謝你的任何想法！
你的服務器有多少內存？這些物體佔用多少內存？把它們全部留在記憶中是否可行？你是否真的需要加速保持內存，而不是在數據庫中進行推送？它確實使它更加複雜以保存在內存中，並且確實增加了硬件需求......您確定需要它嗎？
因爲你描述的所有內容都可以在一個非常簡單的服務器上運行，並放入一個非常簡單的數據庫中，並按照每個請求100毫秒的順序給出結果。你需要超過100毫秒的響應時間？爲什麼？
對象是簡單的POJO包含一些整數和字符串，也許是一個小的字符串列表也。不是太貴，我猜，但是可能有10萬個。我真的不能猜測這是否會佔用體面的計算機上的大量內存。 我在考慮替代品，因爲SQL查詢將主要涉及I/O磁盤操作。從內存中獲取結果將會快很多。現在，如果沒有任何簡單的替代品（也許我錯過了易用的東西），那麼當然我會去DB。 – Matthew 2010-07-25 16:38:56
數據庫自然會將正在使用的內容保存在內存中。它還將使用索引來加快查詢速度。對於幾條100k簡單記錄，您可以查詢和檢索100ms內的信息。十分之一秒太長？在記憶中這樣做沒有任何問題，但是你真的需要快速的要求（可能是1/100秒和1/10秒）來解決這個問題。 – bwawok 2010-07-25 17:57:20
絕對是一個關係數據庫。有了這個大小，你將需要一個客戶端 - 服務器系統，而不是像Sqlite那樣嵌入的東西。根據進一步的要求選擇一個系統。索引是一項基本功能，大多數系統都支持它。就我個人而言，我會嘗試一些非常流行和免費的東西，例如MySQL或PostgreSQL，這樣您可以更輕鬆地通過Google找到解決問題的方法。如果你使你的SQL查詢足夠通用（沒有供應商特定的結構），你可以切換系統而不會有太大的痛苦。我同意bwawok，試試標準設置是否足夠好，然後再考慮優化。
爲什麼不嵌入一些東西？它不是更快嗎？你能澄清一下嗎？我正在尋找像H2 DB這樣的東西。 – Matthew 2010-07-25 16:41:14
H2可能會也可能不會更快。但是，在你走上這條路之前，你真的需要業務需要，因爲你最終可能會將自己裝進未來的角落。 – bwawok 2010-07-25 17:58:25
我必須說，我從來沒有嘗試使用Sqlite 3的100K行表，也許它工作正常，只要你沒有多個用戶同時嘗試更新數據庫。但它將全部放在常規文件系統的單個常規文件中，對我來說似乎很腥。盡一切辦法嘗試一下;您還可以嘗試Firebird，它支持嵌入式和客戶端 - 服務器訪問，並且具有一些強大的功能，但不像其他系統那麼受歡迎。 – reinierpost 2010-07-25 23:33:09
我會使用RDBMS--有很多好的ORM可用，比如Hibernate，它們允許你透明地將POJO填充到數據庫中。一旦將數據訪問抽象出來，您就可以自由決定如何最好地保存數據。
對於這個規模的項目，我會使用H2 database。它具有嵌入式和客戶端/服務器兩種模式，可以從磁盤或完全在內存中運行。
如果在內存中存儲是需求，則用於內存數據庫的+1。由於對象模型是微不足道的（1個表/類），因此不推薦使用hibernate作爲這種情況。 – 2010-07-25 20:14:33
我在考慮可搜索因素--Hibernate標準API比動態構建SQL查詢更容易構建對任意屬性和值的搜索。此外，hibernate隨着您的項目帶來有用的功能而增長，特別是與Spring結合使用時（聲明式事務，審計和插入持久層的各種鉤子 - 攔截器）有助於實現良好的結構。 – mdma 2010-07-26 18:47:46
您是否想過使用EHCache或Memcached等緩存系統？ 另外如果你有足夠的內存，你可以使用像TreeMap這樣的一些排序的集合作爲索引映射，或者使用HashMap來按名稱搜索用戶（每個字段單獨映射）。這將需要更多的記憶，但可以有效。您還可以根據用戶查詢體驗找到具有最佳選擇性的最常用查詢，並根據此查詢創建比較器。在這種情況下，元素的子集不會很大，並且可以快速過濾而不需要任何額外的優化。
聽起來像是一個數據庫... 0034 – 2010-07-25 22:28:47