哪个结构在主机服务器、平面文件或数据库 (mysql) 上返回更快的结果和/或更少的负担？
假设许多用户(100 个用户)同时查询文件/数据库。 搜索涉及针对静态文件/数据库的模式匹配。 文件有 50,000 行(相同的数据类型)。 可能会有很多比赛。 没有写入文件/数据库，只是读取。
如果主文件正在使用，是否可以复制文件/数据库并编写逻辑开关以使用备份文件/数据库？
哪种语言最适合结构类型？ Perl for flat 和 PHP for db？
附加信息:
如果我想查找所有城市的名称中都有“cis”模式。 使用正则表达式或字符串函数哪个更好/更快？
请推荐一个策略
TIA
最佳答案
我非常喜欢简单的解决方案，因此对于简单的任务，我更喜欢平面文件存储。具有索引功能的关系数据库根本无法帮助您处理任意正则表达式模式，并且文件系统的缓存确保这个相当小的文件无论如何都在内存中。我会选择平面文件 + perl 路线。
编辑:(将您的新信息考虑在内) 如果真的只是在一个已知属性中查找子字符串，那么使用全文索引(由数据库提供)会对您有所帮助(取决于所应用的索引类型)并且可能会提供一个简单且相当快速的解决方案来满足您的要求。当然，你可以在文件系统上自己实现一个索引，例如使用 Suffix Tree 的变体，在速度方面很难被击败。
不过，我还是会选择平面文件路线(如果它符合您的目的，请查看 awk)，因为如果您已经开始实现它，那么您就已经完成了 ;)此外，我怀疑您所谈论的用户数量不会让系统感受到差异(无论如何，您的 CPU 大多数时间都会感到无聊)。
如果你不确定，那就试试吧!实现正则表达式+perl 解决方案，如果您了解 perl，则需要几分钟，循环 100 次并使用 time 进行测量。如果足够快，就使用它，如果不够快，考虑其他解决方案。您必须记住，就现代计算而言，您的 50,000 条唯一行确实是一个很小的数字。 (与此比较:Optimizing Mysql Table Indexing for Substring Queries)
HTH,
亚历山大
关于数据库 vs 平面文件，对于 "regex"匹配许多同时请求，这是一种更快的结构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2887463/