eBay数据优化技巧(ebay怎么优化产品)
本文目录
ebay的广告应该怎么优化技巧介绍
eBay推广是可以使用付费广告的，毕竟在操作上十分的通俗易懂，就算是新手卖家，也能很快上手。而且只有产生购买才会收取广告费。那ebay的广告应该怎么优化?
首先，基于不同产品分别创建广告组，建议卖家优先使用eBay平台推荐的关键词;再者，除了eBay建议关键词外，卖家也可添加自定义关键词。
即在主关键词的基础上增加同义、近义的长尾关键词，通过大量测试来匹配和拓展更多、更精准的关键词。
其次，设置否定关键词，屏蔽非目标用户画像的关键词或排除词匹配中表现不佳的关键词，使系统停止在这些关键词的搜索结果中投放广告，以避免不相关关键词的CPC广告成本支出。
同样，建议卖家优先使用eBay推荐的建议竞价。
在选择关键字后，Jeffry
Radspinner通常会将广告竞价设置为：每次点击0.1$或0.2$，预算为10$/天或者20$/天，以期用少量预算测试新的广告来获取广告数据，帮助进一步调整优化广告设置。
大型品牌广告主要是针对那些具备大量营销频率以及预算的品牌，通过eBay的品牌解决方案优化产品的listing。这样的推广方式会更加深入并且赋予了个性化的标志。
在广告投放初期，前半个月是获取数据的基础阶段，一旦我们创建好广告投放设置，15-30天之间就可以看到明显的效果了。
在投放广告的过程中如何花费最少的费用获得最大的流量，我们需要研究分析每个地区的流量高峰阶段。举个例子，美国的流量巅峰时段一般在早上的8-9点、中午12-14点，还有晚上的8-12点，在这些高峰值我们需要根据自身产品的属性加大力度去投放，而其他时间投放的费用可以相应减少。
有些卖家不同的产品对应的流量时间段不同，如果能够将产品分开不同的时间重点推广，那就实现无缝衔接的曝光和订单收入了。
以上就是ebay广告优化的技巧介绍了。在广告投放初期，前半个月是获取数据，需要等15-30天才能看到明显的效果。
亿级Elasticsearch 性能优化
最近一年使用 Elasticsearch完成亿级别日志搜索平台「ELK」，亿级别的分布式跟踪系统。在设计这些系统的过程中，底层都是采用 Elasticsearch来做数据的存储，并且数据量都超过亿级别，甚至达到百亿级别。
所以趁着有空，就花点时间整理一下具体怎么做 Elasticsearch性能优化，希望能对 Elasticsearch感兴趣的同学有所帮助。
Elasticsearch是一个基于 Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于 RESTful web接口。Elasticsearch是用 Java开发的，并作为 Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
作为一个开箱即用的产品，在生产环境上线之后，我们其实不一定能确保其的性能和稳定性。如何根据实际情况提高服务的性能，其实有很多技巧。
下面我就从三个方面分别来讲解下优化服务的性能：
索引优化主要是在 Elasticsearch插入层面优化，如果瓶颈不在这块，而是在产生数据部分，比如 DB或者 Hadoop上，那么优化方向就需要改变下。同时，Elasticsearch本身索引速度其实还是蛮快的，具体数据，我们可以参考官方的 benchmark数据。
当有大量数据提交的时候，建议采用批量提交。
比如在做 ELK过程中，Logstash indexer提交数据到 Elasticsearch中，batch size就可以作为一个优化功能点。但是优化 size大小需要根据文档大小和服务器性能而定。
像 Logstash中提交文档大小超过 20MB，Logstash会请一个批量请求切分为多个批量请求。
如果在提交过程中，遇到 EsRejectedExecutionException异常的话，则说明集群的索引性能已经达到极限了。这种情况，要么提高服务器集群的资源，要么根据业务规则，减少数据收集速度，比如只收集 Warn、Error级别以上的日志。
优化硬件设备一直是最快速有效的手段。
为了提高索引性能，Elasticsearch在写入数据时候，采用延迟写入的策略，即数据先写到内存中，当超过默认 1秒（index.refresh_interval）会进行一次写入操作，就是将内存中 segment数据刷新到操作系统中，此时我们才能将数据搜索出来，所以这就是为什么 Elasticsearch提供的是近实时搜索功能，而不是实时搜索功能。
当然像我们的内部系统对数据延迟要求不高的话，我们可以通过延长 refresh时间间隔，可以有效的减少 segment合并压力，提供索引速度。在做全链路跟踪的过程中，我们就将 index.refresh_interval设置为 30s，减少 refresh次数。
同时，在进行全量索引时，可以将 refresh次数临时关闭，即 index.refresh_interval设置为-1，数据导入成功后再打开到正常模式，比如 30s。
Elasticsearch默认副本数量为 3个，虽然这样会提高集群的可用性，增加搜索的并发数，但是同时也会影响写入索引的效率。
在索引过程中，需要把更新的文档发到副本节点上，等副本节点生效后在进行返回结束。使用 Elasticsearch做业务搜索的时候，建议副本数目还是设置为 3个，但是像内部 ELK日志系统、分布式跟踪系统中，完全可以将副本数目设置为 1个。
当我们查询文档的时候，Elasticsearch如何知道一个文档应该存放到哪个分片中呢？它其实是通过下面这个公式来计算出来
routing默认值是文档的 id，也可以采用自定义值，比如用户 id。
在查询的时候因为不知道要查询的数据具体在哪个分片上，所以整个过程分为 2个步骤
查询的时候，可以直接根据 routing信息定位到某个分配查询，不需要查询所有的分配，经过协调节点排序。
向上面自定义的用户查询，如果 routing设置为 userid的话，就可以直接查询出数据来，效率提升很多。
Ebay曾经分享过他们使用 Elasticsearch的经验中说到：
Elasticsearch针对 Filter查询只需要回答「是」或者「否」，不需要像 Query查询一下计算相关性分数，同时 Filter结果可以缓存。
在使用 Elasticsearch过程中，应尽量避免大翻页的出现。
正常翻页查询都是从 From开始 Size条数据，这样就需要在每个分片中查询打分排名在前面的 From+ Size条数据。协同节点收集每个分配的前 From+ Size条数据。协同节点一共会受到 N*（ From+ Size）条数据，然后进行排序，再将其中 From到 From+ Size条数据返回出去。
如果 From或者 Size很大的话，导致参加排序的数量会同步扩大很多，最终会导致 CPU资源消耗增大。
可以通过使用 Elasticsearch scroll和 scroll-scan高效滚动的方式来解决这样的问题。具体写法，可以参考 Elasticsearch:权威指南- scroll查询
Elasticsearch默认安装后设置的堆内存是 1 GB。对于任何一个业务部署来说，这个设置都太小了。
比如机器有 64G内存，那么我们是不是设置的越大越好呢？
其实不是的。
主要 Elasticsearch底层使用 Lucene。Lucene被设计为可以利用操作系统底层机制来缓存内存数据结构。 Lucene的段是分别存储到单个文件中的。因为段是不可变的，这些文件也都不会变化，这是对缓存友好的，同时操作系统也会把这些段文件缓存起来，以便更快的访问。
如果你把所有的内存都分配给 Elasticsearch的堆内存，那将不会有剩余的内存交给 Lucene。这将严重地影响全文检索的性能。
标准的建议是把 50％的可用内存作为 Elasticsearch的堆内存，保留剩下的 50％。当然它也不会被浪费，Lucene会很乐意利用起余下的内存。
同时了解过 ES的同学都听过过「不要超过 32G」的说法吧。
其实主要原因是：JVM在内存小于 32 GB的时候会采用一个内存对象指针压缩技术。
在 Java中，所有的对象都分配在堆上，并通过一个指针进行引用。普通对象指针（OOP）指向这些对象，通常为 CPU字长的大小：32位或 64位，取决于你的处理器。指针引用的就是这个 OOP值的字节位置。
对于 32位的系统，意味着堆内存大小最大为 4 GB。对于 64位的系统，可以使用更大的内存，但是 64位的指针意味着更大的浪费，因为你的指针本身大了。更糟糕的是，更大的指针在主内存和各级缓存（例如 LLC，L1等）之间移动数据的时候，会占用更多的带宽.
所以最终我们都会采用 31 G设置
假设你有个机器有 128 GB的内存，你可以创建两个节点，每个节点内存分配不超过 32 GB。也就是说不超过 64 GB内存给 ES的堆内存，剩下的超过 64 GB的内存给 Lucene
