Installing Tensorflow with GPU requires you to have NVIDIA GPU. AMD video cards are not supported with tensorflow. NVIDIA uses low level GPU computing system called CUDA. It is an NVIDIA proprietary software.
One can go the OpenCL way with AMD but as of now it won’t work with tensorflow.
Also, all NVIDIA devices are not supported. Here is a list from the NVIDIA documentation listing the supported GPUs.
By the end of it, Vivek also shows us a simple trained model.
The good thing is that a lot of functions are available. For instance, we can get shortest paths between two specific nodes. And we can give appropriate colors to the nodes that we’ll cross:
> V(iflo)$color[L[2:4]]=”light blue”
Click through for a demo-heavy example.
The query above is designed to not be able to take advantage of parallelism. The useless repartition streams step and the spill to tempdb suggest that the query might perform better with a
MAXDOP 1hint. With a
MAXDOP 1hint the query runs with an average time of 2473 ms. There is no longer a spill to tempdb.
What happens if the query is run with
MAXDOP 3? Earlier I said that the hashing function or thread boundaries can change based on DOP. With
MAXDOP 3I get a much more even row distribution on threads:
I think the number of cases where it makes sense to use a specific, non-1 MAXDOP hint is pretty small, but here’s one of them. The problem is that if this data changes regularly, the skewness of the data could change along with it, making your brilliant optimization unnecessary or even harmful.
Umachandar Jayachandran and team have been busy. First, they announced a preview of SQL Server ML Services in Azure SQL Database:
In-database Machine Learning support was added in SQL Server 2016 and we are now bringing the same functionality to Azure SQL Database. You can now train and score machine learning models in Azure SQL Database and the predictions can be exposed to any application using your database, easily and seamlessly.
The preview functionality allows you to train and score machine learning models using data that fits in memory (in R data frame). Please note that the amount of memory available for R scripts execution depends on the edition of the Azure SQL database and cannot be modified.
No Python support there yet, but it’s upcoming. Second, we can use the PREDICT function in Azure SQL Database:
Today we are announcing the general availability of the native PREDICT Transact-SQL function in Azure SQL Database. The PREDICT function allows you to perform scoring in real-time using certain RevoScaleR or revoscalepy models in a SQL query without invoking the R or Python runtime.
The PREDICT function support was added in SQL Server 2017. It is a table-valued function that takes a RevoScaleR or revoscalepy model & data (in the form of a table or view or query) as inputs and generates predictions based on the machine learning model. More details of the PREDICT function can be found here.
There are a limited number of models which support PREDICT—things like linear and logistic regression, RevoScaleR’s fast decision trees, etc. If you have this type of model, however, the predictions stay within SQL Server and end up being much faster than going out to R.
There are different query_id values in sys.query_store_query, as well as different entries for each query in sys.query_store_query_text. Both queries are still tied to the stored procedure (object_id 1483152329) which can be confusing if you don’t understand what occurred. In order to confirm which query has executed most recently, you can use the query below, which joins both system views (replace the query_ids as appropriate)
This is a good thing to keep in mind if you perform formatting changes on procedures.
Let’s say you get a request or maybe the developer adds a column in the middle of the table. What happens to the view? Was it created with SELECT *? Could the title of this post just as easily have been “Don’t SELECT * ever again!”? Sure…
This is exactly what had happened. The table was altered and the view didn’t change. The view was actually throwing a date from string conversion error.
Let’s take a peek at the after math of adding a column without rebuilding the view.
To Daniel’s two take-aways I would add a third: don’t use the GUI to insert columns in the middle of a table. The order of columns in a relational table is ultimately irrelevant, so add new columns at the end. That avoids this problem altogether.
Recently I had a requirement to combine data that I already had in SQL Server (2016)with JSON document data already stored in Azure CosmosDB. Both databases were operational and continuously accepting data so I didn’t want to go to the trouble of doing the delta load thing between them, instead I just wanted to be able to query directly on demand.
And so – the purpose of this article is to outline the method to connect direct to Azure CosmosDB from SQL Server using a SQL Linked Server.
Click through for the step-by-step details. Ultimately, it’s a linked server connecting via ODBC, so nothing magical—but it is nice to see interoperability.