英文:
Shopware 6 partitioning
问题
有人有数据库分区的经验吗？我们已经有大量的数据，对其进行的查询已经开始变慢。也许有人有一些示例？这些表与订单相关。
英文:
Has anyone had any experience with database partitioning? We already have a lot of data and queries on it are already starting to slow down. Maybe someone has some examples? These are tables related to orders.
答案1
得分: 2
自版本6.4.12.0开始，Shopware支持使用数据库集群，详见相关文档。您需要首先设置多个只读节点。然后，读取数据的负载将分布在这些只读节点之间，而写操作将受到主节点的限制。
请注意，在集群设置中，您还应该使用锁存储来完善设置。
英文:
Shopware, since version 6.4.12.0, allows the use of database clusters, see the relevant documentation. You will have to set up a number read-only nodes first. The load of reading data will then be distributed among the read-only nodes while write operations are restricted to the primary node.
Note that in a cluster setup you should also use a lock storage that compliments the setup.
答案2
得分: 1
除了使用数据库集群，您还可以尝试减轻数据库服务器的负载。
首先，您应该启用HTTP缓存，最好还要设置一个反向缓存，如Varnish。这将大大减少命中您的Web服务器以及数据库服务器的请求数量。
此外，这里解释的所有措施应该改善您商店的整体性能，并减轻数据库的负载。
另外，您可以使用Elasticsearch，这样昂贵的搜索请求就不会影响到数据库。并使用一个“真正的”消息队列，这样消息就不会存储在数据库中。还可以使用Redis来存储性能关键信息，正如在这个官方文档类别中所记录的。
所有这些措施的影响可能取决于您具体的项目设置，因此也许您可以从数据库锁中看到一些提示，指向我之前提到的一些点，这将是开始的方向指示器。例如，如果您看到与搜索相关的查询很多，那么Elasticsearch可能是一个很好的起点，但如果您看到很多来自写入/读取/删除消息的数据库负载，那么消息队列可能是一个更好的起点。
总之，当您使用具有主数据库和多个副本的数据库集群，并使用我在这里提到的附加服务时，您的商店应该能够在不需要对实际数据库进行分区的情况下实现良好的扩展。
英文:
Besides using a DB cluster you can also try to reduce the load of the db server.
The first thing you should enable the HTTP-Cache, still better to additionaly also set up a reverse cache like varnish. This will greatly decrease the number of requests that hit your webserver and thus your DB server as well.
Besides all those measures explained here should improve the overall performance of your shop as well as decreasing load on the DB.
Additionally you could use Elasticsearch, so that costly search requests won't hit the Database. And use a "real" MessageQueue, so that the messages are not stored in the Database. And use Redis instead of the database for the storage of performance critical information as is documented in the articles in this category of the official docs.
The impact of all those measures probably depends on your concrete project setup, so maybe you see in the DB locks something that hints to one of the points i mentioned previously, so that would be an indicator to start in that direction. E.g. if you see a lot of search related queries Elasticsearch would be a great start, but if you see a lot of DB load coming from writing/reading/deleting messages, then the MessageQueue might be a better starting point.
All in all when you use a DB cluster with a primary and multiple replicas and use the additional services i mentioned here your shop should be able to scale quite well without the need for partitioning the actual DB.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论