I'm trying to implement Load Balancing in Django using Round robin method. At First I created model where I kept all instances and a sequence of each instance.
My Model:
class Load_Balancing(models.Model):
id = models.AutoField(primary_key=True)
instance = models.CharField(max_length=100)
sequence = models.IntegerField()
Don't try to implement load balancing on application level as it makes no sense.
Your database would be bottleneck in your solution.
use proper HTTP server/reverse proxy most of them have well established load-balancing support for example: nginx, apache
Unaware of your intentions with getting an instance in your view and doing whatever further operations with it, below could be a simple PoC to achieve this.
However I strongly recommend you to go with iklinac's solution and reconsider your architecture design.
You can create a model which serves as a counter for you.
Note that this can also be done using an inmemory persistent solution like pickle but I prefer doing this way.
Create a table which acts as a counter
class InstanceSq(models.Model):
sequence_id = models.IntegerField()
Table for this model will always only contain 1 row.
Get it in your views.py as below:
try:
sequence_id = InstanceSq.objects.get(id=1).sequence_id
except InstanceSq.DoesNotExist:
#This is when it runs first time
instance_row = InstanceSq(sequence_id = 1)
instance_row.save()
sequence_id = 1
#..
#Here you get the current instance as:
instance_ip = Load_Balancing.objects.filter(sequence=sequence_id)
#Use your instance here and do whatever you want to do
#.. and then
# Rotation logic
new_id = sequence_id % 4 + 1
current = InstanceSq.objects.select_for_update().get(id=1) #to avoid race conditions
current.sequence_id = new_id
current.save()
Related
I want to ask if there is a convenient way that allows me to create a django model from multiple tables. I am looking for solution, that can be written in similar way:
class ClientTeamContacts(models.Model):
attribute_1 = models.CharField(db_column='ss',db_table = 'xxx')
attribute_2 = models.CharField(db_column='cc',db_table = 'yyy')
I will be thankful for every suggestion that can provide some solution.
Unfortunately, without hacking the django core, I think the best you can hope for is something like this:
class ClientTeamContacts(models.Model):
attribute_1 = models.ForeignKey('xxx', on_delete=models.CASCADE)
attribute_2 = models.ForeignKey('yyy', on_delete=models.CASCADE)
This will let you access and modify SS and CC despite them living on a different table.
record = ClientTeamContacts.objects.get(xxx.ss = 'Smith')
record.xxx.ss = 'Brown'
record.save()
Alternatively, look into using abstract base classes, they abstract out common data and may provide a different way to solve your problem:
https://docs.djangoproject.com/en/2.0/topics/db/models/#abstract-base-classes
I'm working on a web app that needs to consolidate several tables into a single User class. The problem is that certain users will need to be linked to one table and others to another. This is a general view of how my models are set up.
class User(Model):
IDType1 = Column(Integer())
IDType2 = Column(Integer())
Active = Column(Boolean())
#...
class OtherType1(Model):
ID = Column(Integer())
Active = Column(Boolean())
#...
class OtherType2(Model):
ID = Column(Integer())
Active = Column(Boolean())
#...
Each OtherType has a flag marking them as active or inactive and it's updated with relative frequency. I want to be able to check if the User is active which in turns means I have to variably check if their respective flag is marked as active. Ideally I'd like to perform the query below but I don't know if that's possible.
query = User.query.filter(User.is_active==True)
The best option I can think of is to have a method called active_users which creates a basic Query with the Join/Where statements in place but I'm curious if there's a better way.
You have to use the Model.query.filter_by method for this.
So your query would be something like:
User.query.filter_by(Active=True)
I'd like to create a directed graph in Django, but each node could be a separate model, with separate fields, etc.
Here's what I've got so far:
from bannergraph.apps.banners.models import *
class Node(models.Model):
uuid = UUIDField(db_index=True, auto=True)
class Meta:
abstract = True
class FirstNode(Node):
field_name = models.CharField(max_length=100)
next_node = UUIDField()
class SecondNode(Node):
is_something = models.BooleanField(default=False)
first_choice = UUIDField()
second_choice = UUIDField()
(obviously FirstNode and SecondNode are placeholders for the more domain-specific models, but hopefully you get the point.)
So what I'd like to do is query all the subclasses at once, returning all of the ones that match. I'm not quite sure how to do this efficiently.
Things I've tried:
Iterating over the subclasses with queries - I don't like this, as it could get quite heavy with the number of queries.
Making Node concrete. Apparently I have to still check for each subclass, which goes back to #1.
Things I've considered:
Making Node the class, and sticking a JSON blob in it. I don't like this.
Storing pointers in an external table or system. This would mean 2 queries per UUID, where I'd ideally want to have 1, but it would probably do OK in a pinch.
So, am I approaching this wrong, or forgetting about some neat feature of Django? I'd rather not use a schemaless DB if I don't have to (the Django admin is almost essential for this project). Any ideas?
The InheritanceManager from django-model-utils is what you are looking for.
You can iterate over all your Nodes with:
nodes = Node.objects.filter(foo="bar").select_subclasses()
for node in nodes:
#logic
After building a few application on the gae platform I usually use some relationship between different models in the datastore in basically every application. And often I find my self the need to see what record is of the same parent (like matching all entry with same parent)
From the beginning I used the db.ReferenceProperty to get my relations going, like:
class Foo(db.Model):
name = db.StringProperty()
class Bar(db.Model):
name = db.StringProperty()
parentFoo = db.ReferanceProperty(Foo)
fooKey = someFooKeyFromSomePlace
bars = Bar.all()
for bar in bar:
if bar.parentFoo.key() == fooKey:
// do stuff
But lately I've abandoned this approch since the bar.parentFoo.key() makes a sub query to fetch Foo each time. The approach I now use is to store each Foo key as a string on Bar.parentFoo and this way I can string compare this with someFooKeyFromSomePlace and get rid of all the subquery overhead.
Now I've started to look at Entity groups and wondering if this is even a better way to go? I can't really figure out how to use them.
And as for the two approaches above I'm wondering is there any downsides to using them? Could using stored key string comeback and bit me in the * * *. And last but not least is there a faster way to do this?
Tip:
replace...
bar.parentFoo.key() == fooKey
with...
Bar.parentFoo.get_value_for_datastore(bar) == fooKey
To avoid the extra lookup and just fetch the key from the ReferenceProperty
See Property Class
I think you should consider this as well. This will help you fetch all the child entities of a single parent.
bmw = Car(brand="BMW")
bmw.put()
lf = Wheel(parent=bmw,position="left_front")
lf.put()
lb = Wheel(parent=bmw,position="left_back")
lb.put()
bmwWheels = Wheel.all().ancestor(bmw)
For more reference in modeling. you can refer this Appengine Data modeling
I'm not sure what you're trying to do with that example block of code, but I get the feeling it could be accomplished with:
bars = Bar.all().filter("parentFoo " = SomeFoo)
As for entity groups, they are mainly used if you want to alter multiple things in transactions, since appengine restricts that to entities within the same group only; in addition, appengine allows ancestor filters ( http://code.google.com/appengine/docs/python/datastore/queryclass.html#Query_ancestor ), which could be useful depending on what it is you need to do. With the code above, you could very easily also use an ancestor query if you set the parent of Bar to be a Foo.
If your purposes still require a lot of "subquerying" as you put it, there is a neat prefetch pattern that Nick Johnson outlines here: http://blog.notdot.net/2010/01/ReferenceProperty-prefetching-in-App-Engine which basically fetches all the properties you need in your entity set as one giant get instead of a bunch of tiny ones, which gets rid of a lot of the overhead. However do note his warnings, especially regarding altering the properties of entities while using this prefetch method.
Not very specific, but that's all the info I can give you until you be more specific about exactly what you're trying to do here.
When you design your modules you also need to consider whether you want to be able to save this within a transaction. However only do this if you need to use transactions.
An alternative approach is to assign the parent like so:
from google.appengine.ext import db
class Foo(db.Model):
name = db.StringProperty()
class Bar(db.Model):
name = db.StringProperty()
def _save_entities( foo_name, bar_name ):
"""Save the model data"""
foo_item = Foo( name = foo_name )
foo_item.put()
bar_item = Bar( parent = foo_item, name = bar_name )
bar_item.put()
def main():
# Run the save in a transaction, if any fail this should all roll back
db.run_in_transaction( _save_transaction, "foo name", "bar name" )
# to query the model data using the ancestor relationship
for item in bar_item.gql("WHERE ANCESTOR IS :ancestor", ancestor = foo_item.key()).fetch(1000):
# do stuff
I am setting up a model where two players are involved in a competition. I'm leaning towards this model:
def match(models.Model):
player = ForeignKey(Player)
opponent = ForeignKey(Player)
score = PositiveSmallIntegerField()
games_won = PositiveSmallIntegerField()
games_lost = PositiveSmallIntegerField()
won_match = BooleanField()
There are statistics involved, however, and it would require another pull to find the matching record for the opponent if I want to describe the match in full.
Alternatively I could set up the model to include full stats:
def match(models.Model):
home_player = ForeignKey(Player)
away_player = ForeignKey(Player)
home_player_score = PositiveSmallIntegerField()
away_player_score = PositiveSmallIntegerField()
...
But that seems equally bad, as I would have to do two logic sets for one player (to find his scores when he's home_player and his scores when he's away_player).
The final option is to do two inserts per match, both with full stats, and keep redundant data in the table.
There seems like a better way, and therefore I poll SO.
Id go with the first model and use select_related() to avoid the extra db calls.
If you're looking to reduce redundancy and maintain consistiency of logic...
Match:
- id
- name
Match_Player: (2 records per match)
- match_id
- player_id
- is_home
Match_Player_Score:
- match_id
- player_id
- score
I'd avoid having redundant data in the database. This leaves open the possibility of the database data getting internally inconsistent and messing up everything.
Use a single entry per match, as in your second example. If you plan ahead, you can accomplish the two sets of logic pretty easily. Take a look at proxy models. There might be an elegant way to do this -- have all of your logic refer to the data fields through accessors like get_my_score and get_opponent_score. Then build a Proxy Model class which swaps home and away.
class match(models.Model):
def get_my_score(self):
return self.home_player_score
def get_opponent_score(self):
return self.away_player_score
def did_i_win(self):
return self.get_my_score() > self.get_opponent_score()
class home_player_match(match):
class Meta:
proxy = True
def get_my_score(self):
return self.away_player_score
def get_opponent_score(self):
return self.home_player_score
Or maybe you want two Proxy models, and have the names in the base model class be neutral. The problem with this approach is that I don't know how to convert a class from one proxy model to another without reloading from the database. You want a "rebless" as in perl. You could do this by using containment rather than inheritance. Or maybe just a flag in the wrapper class (not stored in the database) saying whether or not to swap fields. But I'd recommend some solution like that -- solve the tricky stuff in code and don't let the database get inconsistent.