千万级数据如何进行缓存

    1千万左右的数据量，数据有查询次数的限制，比如每条记录每天只能查询2次，每周只能查询5次，每月只能查询10次,现在要求在查询的时候能够很快的反馈是否到达查询次数上限，如果没有记录，则增加此记录的查询次数，每天的查询量非常大，可能达到千万级。
   目前有3个方案去解决这个问题，如下：

方案1. 采用自定义缓存，直接把1千万数据，根据数据标识作为key放到hashmap里面，每次查询的时候就直接根据key去找到相应的记录，并更新对应的查询次数，并定时把记录写到文件里面，防止数据全部丢失，此方案优点是快，缺点是需要太多的内存，如果缓存里面没有这条记录，需要把这条记录也加进去，不知道会不会太慢。

方案2. 采用关系数据库，比如oracle，把这些记录都放到oracle的表里面，每次查询的时候到oracle里面去查，但是这么频繁的操作和这么大的数据量，查询的速度可能会大打折扣，符合不了要求。

方案3. 采用内存数据库，比如fastdb,h2之类的内存数据库，这个不是很熟悉，也没有经验，只是大概的想到可以这么做。

现在倾向于使用方案1，请探讨一下，方案1是否可行？方案2,3是否存在可优化的地方？

不知道方案一里为什么选择写文件而不是数据库。
像你这种简单的key、value的数据库结构是否用no-sql数据库更加合适。或者就直接存数据库+外部cache，数据库量大可以考虑分库。。速度不会太差。、

推荐使用第三种，现在有些小型的内存数据库，也提供多种模式，比如内存存储和文件存储，内存处理速度快，效率高，但不能持久，例如断电就完了，可结合定时同步文件存储来弥补。

不用想了，数据存储肯定是直接通过内存的最快，建议用1和3两种方式，nosql的模式用mongodb呗

缓存+数据库吧，关键是针对记录查询次数限制需要好好考虑，建议可以在缓存中进行查询限制的判断，查询先访问缓存，如果有对应的记录就返回，没有就查询数据库，并将记录放入缓存，下一次查询则可以直接查询缓存。

感觉好几个地方没说清楚：
1、查询次数的限制，应该是针对查询主体，而不是数据对吧。如果是这样，那限制与数据没有太直接的关系，应另行考虑
2、从字面上看，数据查询的特点是容量大查询多，为何不考虑适当切分，多数据库实例分担负载？
3、“把数据写到文件里”感觉是多此一举，数据肯定是持久化了的，否则怎么查？如果数据本身很凌乱，为何不考虑先ETL，整理为模式化了的数据仓库？

建议nosql

1000万而已,2方案存在的问题是你实际碰到的,还是你自己臆想出来的?

1000W别折腾了，通过索引查询很快的

才1000万对oracle来说不算什么的。
不知道你这个查询是根据id来查询还根据什么来查。
个人想法是如果根据id来查询的话。可以以id为key以查询的次数为value进行缓存。这样在查询具体记录之前可以很快的给出查询次数。防止了不必要的数据库查询操作。之后再去库时查。