[
https://issues.apache.org/jira/browse/ARTEMIS-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15967635#comment-15967635
]
clebert suconic commented on ARTEMIS-839:
-----------------------------------------
I talked to Matt... lets keep the JIRA. We may need to keep this JIRA.
AMQ5 was hitting a limit earlier due to its architecture. Artemis has the
capacity to batch writes and syncs...
however.. you can't ever overcome physical limitations of the hardware. Lets
say you have muliple slow disks... if you separate multiple journals you may be
able to have a higher througput on the broker.
The reason I down played this JIRA was actually containers and virtualization.
I thought users would span a new broker for a new disk these days.. but Matt
said this is not what he had seen in deployed customers...
So, unless someone disagrees and thinks containers won't fix this... we still
need this JIRA eventually.
This is more or less the summary of my talk to Matt on IRC today at
#apache-activemq
> Support multiple backend data stores
> ------------------------------------
>
> Key: ARTEMIS-839
> URL: https://issues.apache.org/jira/browse/ARTEMIS-839
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
> Reporter: Matt Pavlovich
>
> ActiveMQ 5.x supports multi-kahahdb where destinations matching a certain
> naming convention are stored in separate data stores in order to overcome
> disk I/O performance issues
> Artemis should support this to achieve parity with ActiveMQ and other
> commercial brokers, such as Tibco EMS that support multiple back-end data
> stores.
> The 2 primary use cases:
> 1. Increase overall disk I/O by having multiple mount points to allow busy
> destinations to have separate disks
> 2. Separate *.*.*.DLQ destinations in order to avoid the
> journal-cannot-be-cleaned-up issue due to sporadic messages still present
> Note: It was discussed on IRC that #2 may be mitigated with Artemis'
> compaction thread. However, with very large data stores the performance would
> be better with a partitioned data store vs one really large one.
> Enhancement: It would be great if the full path could be specified.
> Currently, in ActiveMQ 5.x the path is automatically generated based on the
> destination name filter and complicates the ability to separate destinations
> due to funky character names on all OS's and filesystems.
> For example, support multiple journal entries ad add an attribute:
>
> * "destination-filter" or similar
> Examples:
>
> * < ... destination-filter="Order.>"
> * < .. destination-filter="Billing.>"
> * < .. destination-filter=">"
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
