EPiServer DXC and SqlBlobProvider

Vote:
 

Hi

I am not sure if I post this in the right forum, but I did not find a forum for EPiServer DXC.

At my company we are building a new site thats going to be hosted in EPiServer DXC. It says here: https://world.episerver.com/digital-experience-cloud-service/deploying/creating-a-new-cms-site-and-deploying/

that you should change to the following settings:

<episerver.framework>
	<blob defaultProvider="azureblobs">
		<providers>
			<add name="azureblobs" connectionStringName="EPiServerAzureBlobs" container="mysitemedia" type="EPiServer.Azure.Blobs.AzureBlobProvider,EPiServer.Azure" />
		</providers>
	</blob>
	<event defaultProvider="azureevents">
		<providers>
			<add name="azureevents" connectionStringName="EPiServerAzureEvents" topic="MySiteEvents" type="EPiServer.Azure.Events.AzureEventProvider,EPiServer.Azure" />
		</providers>
	</event>
</episerver.framework>

I would like to use the SqlBlobProvider

<episerver.framework>
	<blob defaultProvider="sqlBlobProvider">
		<providers>
			<add name="sqlBlobProvider" type="EPiCode.SqlBlobProvider.SqlBlobProvider, EPiCode.SqlBlobProvider" />
		</providers>
	</blob>
	<event defaultProvider="azureevents">
		<providers>
			<add name="azureevents" connectionStringName="EPiServerAzureEvents" topic="MySiteEvents" type="EPiServer.Azure.Events.AzureEventProvider,EPiServer.Azure" />
		</providers>
	</event>
</episerver.framework>

My guess is that thats' no problem.

Am I correct?

Regards Hans

#206740
Aug 29, 2019 12:11
Vote:
 

Thank you Ravindra

#206746
Aug 29, 2019 13:18
Vote:
 

Hi,

Is there a specific reason you want to store the blobs in the database? 

#206768
Aug 29, 2019 15:41
Vote:
 

The reason that has been before is that I find it much easier to copy data from one environment to another. Backup and restore to the desired environment database and its done.

But now when its Azure maybe thats not the case anymore.

Is there a specific reason to use Azure-blobs?

Regards Hans

#206769
Aug 29, 2019 15:48
Vote:
 

Performance is probably much better with Blob storage. I have no numbers to back this up though :) But SQL is not really designed for blobs.

You also get much more data to move around when everything is stored in the DB. I guess this could also make deploys slower.

#206770
Aug 29, 2019 15:53
Vote:
 

But if you want to move the blobs to another environment, will not that take time?

Lets say you get your integration environment filled with content thats correct. And you want to move that to preproduction and later production.

We have to move the database content and we have to move the azure-blobs. Is that faster than moving a database with blobs?

Is there an easy way to move the Azure-blobs from integration to, lets say, preproduction?

And if performance is better with Azure blobs thats good. Then it does not matter if moving data takes longer, because that is not what you do every day.

Hope you understand what I mean.

/Hans

#206771
Edited, Aug 29, 2019 16:06
Vote:
 

I just want to note that this is not officially tested on DXC so there is no guarantee that it will work properly. It might, but if you run into problems you will have difficult time getting support. 

#206772
Aug 29, 2019 16:08
Vote:
 

For moving content between environments I would recommend using the export/import funcationality instead.

I typically just backstage the DB and not all blobs if I need the production data locally for debugging purposes. Then it's less data to move. But you are correct, it's still the same amount of data to move if you want to include the blobs.

#206773
Aug 29, 2019 16:09
Vote:
 

@Quan Mai

Just to be sure. Do you mean that the SqlBlobProvider is not officially tested?

/Hans

#206774
Aug 29, 2019 16:13
Vote:
 

@Johan Petersson

The old site, we now are building a new one for, we started up with the built in blobprovider. This was before, hosting inhouse. I just remember that if you wanted both database-data and files copied from production to lets say, stage. It took a really long time to copy the files over the network, especially when there are a lot of files. Having the blobs in the database for that reason I found much easier. But as I said, its not often you do that. And if you want to make another environment identical regarding data I dont find export/import an easy solution.

If Azure-blobs are faster I will probably go for that.

Thanks

Regards Hans

#206776
Edited, Aug 29, 2019 16:25
Vote:
 

As far as I know - of course I can be wrong here - SqlBlobProvider was not tested by Episerver QAs on DXC. 

#206777
Aug 29, 2019 16:28
Vote:
 

Ok, thanks a lot everyone for your help

Regards Hans

#206780
Aug 29, 2019 16:30
Vote:
 

@Hans sorry for jumping in late on this thread. I agree with @Johan's points. And I have some additional tips/points.

In our local Development environments, our Devs use a separate Container but still inside the same DXC Azure Blob storage used for Integration.

This means on your Local environment the Connection String is the same as Integration, but in the Blob provider config, we set a different Container name (think Folders). You can decide if your Developers share the same Blob Container (we have done this quite successfully), or you each Developer has their own Container.

<blob defaultProvider="azureblobs">
  <providers>
    <add name="azureblobs" type="EPiServer.Azure.Blobs.AzureBlobProvider,EPiServer.Azure" 
    connectionStringName="EPiServerAzureBlobs" container="development-local" />
  </providers>
</blob>

Then we use a Config Transform to set it back to the Integration Environment Container

<blob defaultProvider="azureblobs" xdt:Transform="Remove" />
<blob defaultProvider="azureblobs" xdt:Transform="Insert">
  <providers>
    <add name="azureblobs" type="EPiServer.Azure.Blobs.AzureBlobProvider,EPiServer.Azure" 
    connectionStringName="EPiServerAzureBlobs" container="mysitemedia"/>
  </providers>
</blob>

I'd also add that when moving between environments, while Blobs in the DB is simpler, it also means your Blobs and DB data are coupled together.

Restoring DBs up from Integration -> Pre-production -> Production is really only an option until Production is live, after that you'll use Export/Import. But over time you will likely want to refresh your lower environments from Prod (and most of the time you'll want to include the Blobs), but sometimes you'll just want a bacpac (backup) of Production DB for local debugging. 

For these reasons, plus the possible performance benefits of Azure Blobs vs SQL, I think decoupling the DB from Blobs makes the most sense.

#206875
Edited, Sep 03, 2019 6:21
Vote:
 

Thank you for the tip Darren

/Hans

#206879
Sep 03, 2019 9:50
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.