我有这个简单的代码:
public interface IReader<out T>
{
IEnumerable<T> GetData();
}
这个接口应该在T上协变,我用这种方式:
private static Func<bool> MakeSynchroFunc<T>(IReader<T> reader) where T : IComposite
{
return () => Synchronize(reader);
}
注意T的约束来实现IComposite.同步方法接受IReader<IComposite>输入:
private static bool Synchronize(IReader<IComposite> reader)
{
// ......
}
编译器告诉我它无法转换IReader<T>为IReader<IComposite>尽管T的约束和IReader的协方差.
我在这里做错了吗？编译器应该能够验证约束,协方差应该让我使用我IReader<T>的IReader<Icomposite>,不是吗？
谢谢.
我正在努力将搜索引擎从sql数据库移植到elasticsearch.这样做的主要原因是能够轻松地计算构面.
目前我们通过生成precalc表在sql上有方面.它运行良好,但维护很痛苦,只有数据子集支持facet.
现在ES原型正在工作,我正在对这两个解决方案进行基准测试,看起来ES版本在性能方面略逊于sql版本(在可维护性方面,它要好得多).
我使用了完全相同的机器配置,一个64位平台,32 GB的RAM,一个ssd磁盘和一个3ghz的四核Intel Xeon来比较sql和ES.
文档不小,大约有200个字段,根据请求,使用基于脚本的排序,并且总是在doc的8个字段上计算facet.
该索引包含3百万个文档,如果我没有记错的话它与ES可以处理的相对较小.
在查询方面,我使用过滤查询,对于某些请求,我使用custom_filters_score查询来计算得分并将其用于排序.
由于方面的原因,某些过滤器是全局的,但过滤后的查询中总会有一些过滤器,因此应减少扫描的文档数量(并非所有索引都被扫描).
我在测试中使用了两个度量:服务器执行搜索所花费的时间,以及并行运行100个线程的客户端执行的查询数量.
对于elasticsearch,每个查询在服务器上花费的平均时间大约为500毫秒(并行100个查询),客户端上的平均查询时间大约为160(构建查询,发送它时会丢失一些ms,接收结果并解析它们).这是一个索引有1个碎片和0个副本,当我增加碎片/复制品的数量时,性能显着下降.
对于sql,执行查询所花费的平均时间约为360毫秒(同上,并行运行100个查询),客户端上的平均查询次数约为200.
我知道这很难比较,但由于我对预期的结果一无所知,我想知道是否有人可以评论这些措施.
也许我错过了一些东西,它应该快一个数量级,或者这些是类似环境的典型结果,我不知道.
在我的案例中我能期待什么？您在ES的类似情况下观察到了什么？它是否支持并发请求？在同时进行100次查询时,执行查询的时间是否应该在500毫秒的范围内？有没有办法改善搜索性能？
欢迎任何信息或评论,这是决定工业化原型的重要部分.
谢谢.