Database sharding in 6.2 needs to migrate in DXP

[6年前 に Jaydip Lakhatariya によって更新されました。]

Hi,

Liferay 6.2 has feature of database sharding. For each portal instance we can have different databases, hence data would be separate among all portal instances. We have use the same feature with one of our portal. You can find the reference of this sharding concept from the below link.

https://web.liferay.com/community/wiki/-/wiki/Main/Database+Sharding

Now we need to migrate this existing sharded portal to the Liferay DXP and we have not found any way to use the same feature in liferay dxp. We have explored the liferay dxp source code and could not find any classes related to sharding. Then we got the below link in which it has only mentioned to migrate each sharded database with the default database properties but it has not mentioned how do we access all sharded database just like 6.2.

Does Liferay DXP no longer support sharding functionality ? Can anyone please provide some visibility on this ?

Regards,
Jaydip

[6年前 に Olaf Kock によって更新されました。]

Jaydip Lakhatariya:

Does Liferay DXP no longer support sharding functionality ? Can anyone please provide some visibility on this ?

Correct - sharding is no longer supported. You can however upgrade your environment. From there on, you'll have to leverage your database's partitioning features if you want to achieve similar things.

Sharding has rarely been used for the purpose it was meant to, and also rarely to the advantage of the users. It was always notoriously hard to separate shards from each other, should you ever need to do so. And if you're sharding for performance reasons, it's better to rely on the underlying database anyway, rather than on the application layer.

[6年前 に Jaydip Lakhatariya によって更新されました。]

Thanks Olaf for the better clarification,

But for us it would take more efforts and testing in upgrading our existing sharded portal. We have around 50 sharded databases for each instance and now we need to find other options to make separate database for each site. Either we need to go for database partitioning or we need to merge all instance data into single database. Please suggest if you have any other better option.

Regards,
Jaydip

[6年前 に Olaf Kock によって更新されました。]

Those are the options - you either partition, or you don't.

What's the problem that you've intended to solve with sharding? Evaluate if it's still an issue. It's definitely easier in maintenance to go with a single database.

[6年前 に Jaydip Lakhatariya によって更新されました。]

The problem was our client wants to make separate databases for each instances. Hence we had provided solution to make sharding so that database for each site can be differentiated.

Regards,
Jaydip

[6年前 に Olaf Kock によって更新されました。]

Jaydip Lakhatariya:

The problem was our client wants to make separate databases for each instances. Hence we had provided solution to make sharding so that database for each site can be differentiated.

To me it's always hard to accept "Make it so" as an underlying problem. Because nobody would want to add complexity without any payback. The problem with sharding is that, to my knowledge, you can't really back up individual databases, move them to other portal installations etc - they're intrinsically woven together. E.g. the document library and search index are still shared by all, typically. All you gain is the potential for a slightly faster answer from one database. If that ends up being noticed by the users: I doubt.